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

From mstrauss at openjdk.org  Wed Apr 16 15:36:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 15:36:24 GMT
Subject: RFR: 8345348: CSS media feature queries [v17]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <Do1DJkOulV418LLu-7XxgoeohSsbcpXmAwaT2AoLNJA=.43dc6328-9b81-43f4-bf51-42fd9044ce3c@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:

  Scene preferences only actively observe platform preferences when the scene is showing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/9580a80c..1ecc4fc1

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

  Stats: 222 lines in 4 files changed: 102 ins; 64 del; 56 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  Wed Apr 16 15:55:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 15:55:14 GMT
Subject: RFR: 8345348: CSS media feature queries [v18]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <kP5Wl9kAKEuRtpeu28PZNmDsEE0ad5wB1NhvZ37QWKQ=.255e89fa-8886-414f-b64d-fcf103b3abe5@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:

  remove ReadOnlyBooleanWrapper

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/1ecc4fc1..b897ce08

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

  Stats: 47 lines in 1 file changed: 25 ins; 12 del; 10 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  Wed Apr 16 15:55:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 15:55:14 GMT
Subject: RFR: 8345348: CSS media feature queries [v13]
In-Reply-To: <jlPI_eqMSiPEkFIxt11ZWnW9Qpw6QdKuJamw7wtqhdo=.06f3a435-629b-4d5b-8ee1-ab54bdd913f7@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>
 <jlPI_eqMSiPEkFIxt11ZWnW9Qpw6QdKuJamw7wtqhdo=.06f3a435-629b-4d5b-8ee1-ab54bdd913f7@github.com>
Message-ID: <pCv_yCuq3XAG53C0eg72ia7MQtv-ChGSWQp7324SXd4=.45b122f6-63c5-44c9-a478-44f726964fac@github.com>

On Mon, 14 Apr 2025 12:44:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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.

I've decided to go with option 2.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2047234821

From mstrauss at openjdk.org  Wed Apr 16 16:35:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 16:35:40 GMT
Subject: RFR: 8345348: CSS media feature queries [v19]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <_nsardFfd-w_sncI9mVLMhY9hYdutabRObpo2DS53nA=.3acc34e5-5657-47b6-a180-3734d0a6199f@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:

  reorder fields

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/b897ce08..52b5db8f

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

  Stats: 4 lines in 1 file changed: 2 ins; 2 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 angorya at openjdk.org  Wed Apr 16 16:48:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 16:48:03 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: <YMvG-nP83npH3A-02AxDNzdRm6hqsbttypodqrCsDqQ=.c25916c4-9668-4165-9674-d9f19fc9470c@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.

Looks good.

Do you know if there is an easy way to find similar issues elsewhere?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1780#pullrequestreview-2773199254

From kcr at openjdk.org  Wed Apr 16 16:48:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 16:48:48 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest [v2]
In-Reply-To: <79K9NXxOwFi65KCP1-ZGTHvS_7Is_NaiNGU0JWvvtTg=.8442f221-a6b3-4127-9eb8-9045dbe29d14@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <79K9NXxOwFi65KCP1-ZGTHvS_7Is_NaiNGU0JWvvtTg=.8442f221-a6b3-4127-9eb8-9045dbe29d14@github.com>
Message-ID: <6gBk01gbOzcgJ1PABYapo8bE1Lz-Zd2O6vHPdMOyq0s=.631dd7a8-a8d6-4ec9-b114-4deb1536a28b@github.com>

On Fri, 11 Apr 2025 17:06:38 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.
>> 
>> 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

Avoiding the case where we transition from `FAILED` or `SUCCEEDED` to `CANCELLED` is good, and should fix the test failures (although I'll do some additional testing), but I can't help wondering if underlying problem is something else. The question I have is: _how_ do we get into a state where Worker.State of the Task one of the completion states (`FAILED` or `SUCCEEDED`), whereas the parent FutureTask is not completed, and so enters a canceled state. You can see this by instrumenting the code and calling `super.isCancelled()`.

I wonder if the custom service created by `TestServiceFactory` is causing, or contributing to, the problem?

modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java line 1021:

> 1019:                 switch (getState()) {
> 1020:                 case FAILED:
> 1021:                 case SUCCEEDED:

Avoiding transitioning from a one of the completion states to canceled is a good thing. My question, though is: how did we get here? Is this masking some other problem?

modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java line 1041:

> 1039:                     }
> 1040:                 });
> 1041:                 return rv.get();

This is ineffective since you don't wait for the runLater to execute (and waiting could lead to deadlock, so I wouldn't recommend that). I don't think there is anything better than unconditionally returning `flag` when not running on the FX app thread. That's what the current code does (and is what your proposed fix will do most of the time).

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

PR Review: https://git.openjdk.org/jfx/pull/1769#pullrequestreview-2773125312
PR Review Comment: https://git.openjdk.org/jfx/pull/1769#discussion_r2047294396
PR Review Comment: https://git.openjdk.org/jfx/pull/1769#discussion_r2047321781

From angorya at openjdk.org  Wed Apr 16 16:52:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 16:52:01 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: <52nDITR2vfBysnJkmgfkeAmoleGp_rdJiIRj83PqgW4=.8d784c6a-d8f1-4288-b3a2-867041e86197@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

if you merge the latest `master` branch it'll get rid of the build error on windows.

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

PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2810159159

From angorya at openjdk.org  Wed Apr 16 17:08:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 17:08: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: <fS_BuJGl3iizf-zZSZNgd4Kl18lnCKUorQsVNbkeqhw=.f917ddac-a746-44b5-a60c-578a3f1ed862@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.

modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 996:

> 994:         // Needs to be set before needsLayout is updated, as otherwise a listener that
> 995:         // calls isNeedsLayout() might see the old value.
> 996:         layoutFlag = flag;

This is the right change, but I suspect it might cause regression.

The JavaFX entities which call `isNeedsLayout()`:

`VirtualFlow::layoutChildren`
`VirtualFlow::setCellIndex`

We may need to focus on List/Table/Tree/TableViews during testing.

(Anecdata: I've seen continuous layout calls in the TableView before)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1781#discussion_r2047370606

From mhanl at openjdk.org  Wed Apr 16 17:34:57 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 17:34:57 GMT
Subject: Integrated: 8354455: [TestBug] Remove JUnit Vintage Engine with JUnit
 4
In-Reply-To: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
References: <Qgd8XqXYffjAY-KGmBm6AgZBTYxJSAe7L52qj5hP0j4=.8c26247a-9608-4a06-965c-2a060b455f43@github.com>
Message-ID: <_era5Y-dZV5JoI9kC_iemFDMF5ziWEMgomfSc3Q70Jk=.bd00420a-e7e7-47b8-a2b7-63f9b0b5851e@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?~

This pull request has now been integrated.

Changeset: 367a170c
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/367a170c6493f0e795a420488ca689569031d0ea
Stats:     407 lines in 10 files changed: 118 ins; 158 del; 131 mod

8354455: [TestBug] Remove JUnit Vintage Engine with JUnit 4

Reviewed-by: angorya, kcr

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

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

From angorya at openjdk.org  Wed Apr 16 18:08:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 18:08:07 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
Message-ID: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>

Tries to address the mystery of missing graphic in the TabPane overflow menu:

# Overflow Menu Graphic Property in the TabPaneSkin

Andy Goryachev

<andy.goryachev at oracle.com>


## Summary

Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.



## Goals

The goals of this proposal are:

- to allow the application developers to customize the overflow menu items' graphic
- retain the backward compatibility with the existing application code
- clarify the behavior of the skin when the property is null (i.e. the current behavior)



## Non-Goals

The following are not the goals of this proposal:

- disable the overflow menu
- configure overflow menu graphic property via CSS
- add this property to the `TabPane` control itself



## Motivation

The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
an `ImageView` or `Label` with an `ImageView`.

This limitation makes it impossible for the application developer to use other graphic Nodes,
such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
when the tabs in the `TabPane` have no text.

Example:


public class TabPaneGraphicFactoryExample {
    public void example() {
        Tab tab1 = new Tab("Tab1");
        tab1.setGraphic(createGraphic(tab1));

        Tab tab2 = new Tab("Tab2");
        tab2.setGraphic(createGraphic(tab2));

        TabPane tabPane = new TabPane();
        tabPane.getTabs().addAll(tab1, tab2);

        TabPaneSkin skin = new TabPaneSkin(tabPane);
        // set overflow menu factory with the same method as was used to create the tabs
        skin.setMenuGraphicFactory(this::createGraphic);
        tabPane.setSkin(skin);
    }

    // creates graphic Nodes for tabs as well as the overflow menu
    private Node createGraphic(Tab tab) {
        switch (tab.getText()) {
        case "Tab1":
            return new Circle(10);
        case "Tab2":
            return new Canvas(10, 10);
        default:
            return null;
        }
    }
}



## Description

The proposed solution adds the `menuGraphicFactory` property in the `TabPaneSkin` class:


    /**
     * This property allows to control the graphic for the overflow menu items,
     * by generating graphic {@code Node}s when the menu is shown.
     * <p>
     * When this property is {@code null}, the menu provides only the basic graphic copied from the corresponding
     * {@link Tab} - either an {@link ImageView} or a {@link Label} with an {@link ImageView} as its graphic.
     * <p>
     * Changing this property while the menu is shown has no effect.
     *
     * @since 25
     * @defaultValue null
     */

    public final ObjectProperty<Function<Tab, Node>> menuGraphicFactoryProperty() {

    public final Function<Tab,Node> getMenuGraphicFactory() {

    public final void setMenuGraphicFactory(Function<Tab,Node> f) {



## Alternatives

Use graphic in tabs based on the `ImageView`, which is currently compatible with the overflow menu.



## Risks and Assumptions

The risk is minimal, as the proposed solution adds a new property and retains the existing behavior when
this property is not set.

There might be a need to update the application code if the `TabPane` uses a custom skin extended from
the `TabPaneSkin` which declares a property or a method (or methods) with the same signature.



## Dependencies

None.



## References

- [JDK-8353599 TabPaneSkin: add 'menuGraphicFactory' property](https://bugs.openjdk.org/browse/JDK-8353599)
- https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053306.html
- https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053338.html
- https://github.com/andy-goryachev-oracle/Test/blob/main/doc/TabPane/TabPaneGraphicFactory.md

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - graphic factory

Changes: https://git.openjdk.org/jfx/pull/1773/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353599
  Stats: 135 lines in 2 files changed: 100 ins; 17 del; 18 mod
  Patch: https://git.openjdk.org/jfx/pull/1773.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1773/head:pull/1773

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

From mhanl at openjdk.org  Wed Apr 16 18:09:47 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 18:09:47 GMT
Subject: Integrated: 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: <3tvpSiyxJNuTq26KCRD2TuWxMSYXNi7SAN5mpJKY8QE=.61405edc-e94a-4a1d-b465-297225aefd50@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).

This pull request has now been integrated.

Changeset: 75f36dce
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/75f36dce593e6bd0995e7ccb01452056c61e5230
Stats:     12 lines in 1 file changed: 0 ins; 10 del; 2 mod

8354702: [TestBug] LocalDateTimeStringConverterTest Workaround can be removed

Reviewed-by: angorya

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

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

From mstrauss at openjdk.org  Wed Apr 16 18:25:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:25:51 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener
In-Reply-To: <fS_BuJGl3iizf-zZSZNgd4Kl18lnCKUorQsVNbkeqhw=.f917ddac-a746-44b5-a60c-578a3f1ed862@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
 <fS_BuJGl3iizf-zZSZNgd4Kl18lnCKUorQsVNbkeqhw=.f917ddac-a746-44b5-a60c-578a3f1ed862@github.com>
Message-ID: <OvGPdZc7uPuj49s3YGoJ3bsMddbSgkwmEFyfiLJVSvc=.1071e799-5ac8-43b8-9e1b-101eb4ac6a02@github.com>

On Wed, 16 Apr 2025 17:05:55 GMT, Andy Goryachev <angorya 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.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 996:
> 
>> 994:         // Needs to be set before needsLayout is updated, as otherwise a listener that
>> 995:         // calls isNeedsLayout() might see the old value.
>> 996:         layoutFlag = flag;
> 
> This is the right change, but I suspect it might cause regression.
> 
> The JavaFX entities which call `isNeedsLayout()`:
> 
> `VirtualFlow::layoutChildren`
> `VirtualFlow::setCellIndex`
> 
> We may need to focus on List/Table/Tree/TableViews during testing.
> 
> (Anecdata: I've seen continuous layout calls in the TableView before)

It's very unlikely to cause regressions, because `needsLayoutProperty()` is not used anywhere in JavaFX. The only thing that is different now is that a listener added to this property will see the correct value when calling `isNeedsLayout()`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1781#discussion_r2047484643

From mhanl at openjdk.org  Wed Apr 16 18:28:09 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 18:28:09 GMT
Subject: RFR: 8354794: [TestBug] LocalDateTimeStringConverterTest: Not all
 Tests needs to be parameterized
Message-ID: <yQKqEdALoPElZ1XAwHDzPN37Q6EZs9B42SEJizo1wUc=.568db329-68b2-4fd8-96f4-f9f1d76d2a7e@github.com>

As discussed in #1778, those test does not need to be parameterized, we therefore can replace `@ParameterizedTest` and `@MethodSource` with `@Test`.

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

Commit messages:
 - 8354794: [TestBug] LocalDateTimeStringConverterTest: Not all Tests needs to be parameterized

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

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

From angorya at openjdk.org  Wed Apr 16 18:29:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 18:29:53 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: <uxHclxoW4xp1IZ2clZwsFrv_vl1tJaaa9e00BAg9iBs=.fa61a455-3cf5-43a2-96b5-fd0d366032cf@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

complicated, but it works.
I'll re-approve once you fix the whitespace.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1772#pullrequestreview-2773454859

From angorya at openjdk.org  Wed Apr 16 18:31:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 18:31:51 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener
In-Reply-To: <OvGPdZc7uPuj49s3YGoJ3bsMddbSgkwmEFyfiLJVSvc=.1071e799-5ac8-43b8-9e1b-101eb4ac6a02@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
 <fS_BuJGl3iizf-zZSZNgd4Kl18lnCKUorQsVNbkeqhw=.f917ddac-a746-44b5-a60c-578a3f1ed862@github.com>
 <OvGPdZc7uPuj49s3YGoJ3bsMddbSgkwmEFyfiLJVSvc=.1071e799-5ac8-43b8-9e1b-101eb4ac6a02@github.com>
Message-ID: <lfXMSVK_B4mzirxRso1A5AsFlwtWKEeE4miAfxs0NnY=.a69672bd-46fd-4799-8697-fe19866cb80e@github.com>

On Wed, 16 Apr 2025 18:23:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 996:
>> 
>>> 994:         // Needs to be set before needsLayout is updated, as otherwise a listener that
>>> 995:         // calls isNeedsLayout() might see the old value.
>>> 996:         layoutFlag = flag;
>> 
>> This is the right change, but I suspect it might cause regression.
>> 
>> The JavaFX entities which call `isNeedsLayout()`:
>> 
>> `VirtualFlow::layoutChildren`
>> `VirtualFlow::setCellIndex`
>> 
>> We may need to focus on List/Table/Tree/TableViews during testing.
>> 
>> (Anecdata: I've seen continuous layout calls in the TableView before)
>
> It's very unlikely to cause regressions, because `needsLayoutProperty()` is not used anywhere in JavaFX. The only thing that is different now is that a listener added to this property will see the correct value when calling `isNeedsLayout()`.

you are probably right, re:javafx.  applications might listen to this property, though it's rather unlikely.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1781#discussion_r2047492892

From mstrauss at openjdk.org  Wed Apr 16 18:33:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:33:55 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
In-Reply-To: <YMvG-nP83npH3A-02AxDNzdRm6hqsbttypodqrCsDqQ=.c25916c4-9668-4165-9674-d9f19fc9470c@github.com>
References: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
 <YMvG-nP83npH3A-02AxDNzdRm6hqsbttypodqrCsDqQ=.c25916c4-9668-4165-9674-d9f19fc9470c@github.com>
Message-ID: <njqhMEumXQQD6fuSXtNQRYOxLOzgLK_Hls2LQyKTlyw=.fa878559-b1e5-42d7-b201-80b2de37a020@github.com>

On Wed, 16 Apr 2025 16:45:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Looks good.
> 
> Do you know if there is an easy way to find similar issues elsewhere?

Nothing comes to mind, short of checking all usages of the *Wrapper implementations.

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

PR Comment: https://git.openjdk.org/jfx/pull/1780#issuecomment-2810392760

From mstrauss at openjdk.org  Wed Apr 16 18:33:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:33:55 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: <USWRME_GH5uL1zla9fx0jfVrjbiSalwYBDaQnh-wDaw=.78e4d66f-229d-4424-9ee0-f7fc38b9e48f@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.

Seeing as this is a trivial change that has been reviewed by three Reviewers, I'm integrating this PR early because I need this patch for my other PR #1781 (both PRs target the same code, and this will need to go in first to resolve a merge conflict).

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

PR Comment: https://git.openjdk.org/jfx/pull/1780#issuecomment-2810390234

From mstrauss at openjdk.org  Wed Apr 16 18:33:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:33:56 GMT
Subject: Integrated: 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: <ikdw60_zGe2KAffBHDOu8nmvieORCbIWEfvtmH5_7_U=.71371633-2a6b-4bef-a84c-108625487f51@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.

This pull request has now been integrated.

Changeset: bcf2ad53
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bcf2ad530d55b626a638bac907c3f7de5fdb2d93
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8354797: Parent.needsLayoutProperty() should return read-only getter

Reviewed-by: arapte, jhendrikx, angorya

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

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

From mstrauss at openjdk.org  Wed Apr 16 18:36:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:36:49 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener
In-Reply-To: <lfXMSVK_B4mzirxRso1A5AsFlwtWKEeE4miAfxs0NnY=.a69672bd-46fd-4799-8697-fe19866cb80e@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
 <fS_BuJGl3iizf-zZSZNgd4Kl18lnCKUorQsVNbkeqhw=.f917ddac-a746-44b5-a60c-578a3f1ed862@github.com>
 <OvGPdZc7uPuj49s3YGoJ3bsMddbSgkwmEFyfiLJVSvc=.1071e799-5ac8-43b8-9e1b-101eb4ac6a02@github.com>
 <lfXMSVK_B4mzirxRso1A5AsFlwtWKEeE4miAfxs0NnY=.a69672bd-46fd-4799-8697-fe19866cb80e@github.com>
Message-ID: <HzHFL7yTTUnpT5HCRwSNUdK6Vf8osYKEI8RhDkfsd5o=.281bf77f-179f-4f3d-8883-6f12ec821ab1@github.com>

On Wed, 16 Apr 2025 18:29:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> It's very unlikely to cause regressions, because `needsLayoutProperty()` is not used anywhere in JavaFX. The only thing that is different now is that a listener added to this property will see the correct value when calling `isNeedsLayout()`.
>
> you are probably right, re:javafx.  applications might listen to this property, though it's rather unlikely.

Yes, but I don't think there's anything we can do about it short of not fixing the bug...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1781#discussion_r2047499599

From mhanl at openjdk.org  Wed Apr 16 18:42:45 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 18:42:45 GMT
Subject: RFR: 8354797: Parent.needsLayoutProperty() should return read-only
 getter
In-Reply-To: <YMvG-nP83npH3A-02AxDNzdRm6hqsbttypodqrCsDqQ=.c25916c4-9668-4165-9674-d9f19fc9470c@github.com>
References: <kWgnK-TDbj9hW_OJsN0-mVC5ccLqw9ajkQZy9saduGg=.92bbc875-e38b-4ba1-a6a2-d91a538dc138@github.com>
 <YMvG-nP83npH3A-02AxDNzdRm6hqsbttypodqrCsDqQ=.c25916c4-9668-4165-9674-d9f19fc9470c@github.com>
Message-ID: <5UosElZT1l5DdSXqorXHVmAW7PrY8KlLh_Q7TI__To8=.ee169c1b-d143-4865-af0c-f77f315214b8@github.com>

On Wed, 16 Apr 2025 16:45:32 GMT, Andy Goryachev <angorya 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.
>
> Looks good.
> 
> Do you know if there is an easy way to find similar issues elsewhere?

@andy-goryachev-oracle I think one way to actually test something like this could be to use `Archunit`. 
The usecase of it is to actually test the architecture of your code (e.g. a pattern, imports, annotations, ...).

But we need a new dependency, and to write such somewhat complex rules is also not that easy. I used it in the past and I really liked it. So, just FYI.

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

PR Comment: https://git.openjdk.org/jfx/pull/1780#issuecomment-2810414429

From mstrauss at openjdk.org  Wed Apr 16 18:43:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 18:43:01 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener [v2]
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: <c4FQjcKRSp0QEeWQnIYn3Y6DpCLWv5voXMpCAqVX8tk=.dc34a11e-15d1-45dd-a5eb-e3cb49d0605f@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.

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

 - Merge branch 'master' into fixes/needslayout-wrong-value
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java
 - fix
 - failing test

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

Changes: https://git.openjdk.org/jfx/pull/1781/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1781&range=01
  Stats: 28 lines in 3 files changed: 26 ins; 1 del; 1 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 mhanl at openjdk.org  Wed Apr 16 18:53:19 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 18:53:19 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests
Message-ID: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>

With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)

Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.

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

Commit messages:
 - 8169285: Re-enable javafx.swt tests

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

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

From mhanl at openjdk.org  Wed Apr 16 19:04:14 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 19:04:14 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <vY9RFO_WW9smy9Uc4kiP4O3zWc0bL_5lgV1LBw27r5U=.ed635cf0-2f45-4ba0-a69e-593eb30bbf32@github.com>

On Wed, 16 Apr 2025 18:48:09 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
> 
> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.

Checking the GHA build, `IS_FULL_TEST` actually might be needed. Linux fails with `org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]` when creating the `Display`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810485324

From angorya at openjdk.org  Wed Apr 16 19:14:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 19:14:44 GMT
Subject: RFR: 8354794: [TestBug] LocalDateTimeStringConverterTest: Not all
 Tests needs to be parameterized
In-Reply-To: <yQKqEdALoPElZ1XAwHDzPN37Q6EZs9B42SEJizo1wUc=.568db329-68b2-4fd8-96f4-f9f1d76d2a7e@github.com>
References: <yQKqEdALoPElZ1XAwHDzPN37Q6EZs9B42SEJizo1wUc=.568db329-68b2-4fd8-96f4-f9f1d76d2a7e@github.com>
Message-ID: <NaTjtmcuUX6itd0CcqBX29Gx9RLFMS9zQLKF6Ptaf8o=.541b98dc-2c72-4da1-818a-4ac24ea58295@github.com>

On Wed, 16 Apr 2025 18:23:01 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> As discussed in #1778, those test does not need to be parameterized, we therefore can replace `@ParameterizedTest` and `@MethodSource` with `@Test`.

looks good.  thank you for making changes!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1782#pullrequestreview-2773594748

From mstrauss at openjdk.org  Wed Apr 16 19:24:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 19:24:49 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>

On Fri, 11 Apr 2025 18:17:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Tries to address the mystery of missing graphic in the TabPane overflow menu:
> 
> # Overflow Menu Graphic Property in the TabPaneSkin
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
> 
> 
> 
> ## Goals
> 
> The goals of this proposal are:
> 
> - to allow the application developers to customize the overflow menu items' graphic
> - retain the backward compatibility with the existing application code
> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - disable the overflow menu
> - configure overflow menu graphic property via CSS
> - add this property to the `TabPane` control itself
> 
> 
> 
> ## Motivation
> 
> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
> an `ImageView` or `Label` with an `ImageView`.
> 
> This limitation makes it impossible for the application developer to use other graphic Nodes,
> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
> when the tabs in the `TabPane` have no text.
> 
> Example:
> 
> 
> public class TabPaneGraphicFactoryExample {
>     public void example() {
>         Tab tab1 = new Tab("Tab1");
>         tab1.setGraphic(createGraphic(tab1));
> 
>         Tab tab2 = new Tab("Tab2");
>         tab2.setGraphic(createGraphic(tab2));
> 
>         TabPane tabPane = new TabPane();
>         tabPane.getTabs().addAll(tab1, tab2);
> 
>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>         // set overflow menu factory with the same method as was used to create the tabs
>         skin.setMenuGraphicFactory(this::createGraphic);
>         tabPane.setSkin(skin);
>     }
> 
>     // creates graphic Nodes for tabs as well as the overflow menu
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2":
>             return new Canvas(10, 10);
>         default:
>             return null;
>         }
>     }
> }
> 
> 
> 
> ## Description
> 
> The proposed solution adds the `menuGraphicFactory` property in the `TabPaneSkin` class:
> 
> 
>     /**
>      * This property allows to control the graphic for the overflow menu items,
>      * by generating graphic {@code Node}s when the menu is shown.
>      * <p>
>      * When this property is {@code null}, the...

It may be worth considering to have `TabPaneSkin.menuGraphicFactory` come with a default factory (instead of being `null` by default) that implements the current behavior, and then have `null` mean "I want no overflow menu". I think this would be cleaner than a `null` value implying a default factory.

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2810540457

From angorya at openjdk.org  Wed Apr 16 19:29:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 19:29:51 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
Message-ID: <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>

On Wed, 16 Apr 2025 19:22:00 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> then have null mean "I want no overflow menu"

An interesting suggestion.

This would be a much larger change, since we would have to remove the button as well.  Also, the `menuGraphicFactory` seems rather unrelated to the overflow menu button - an RFE with a boolean property might be better choice.

(you can probably tell I am against this idea ;-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2810552890

From john at status6.com  Wed Apr 16 19:35:01 2025
From: john at status6.com (John Neffenger)
Date: Wed, 16 Apr 2025 12:35:01 -0700
Subject: Proposal: A new common Image API
In-Reply-To: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
Message-ID: <0caed3d7-3b9a-408c-8752-54a69fd84129@status6.com>

On 4/16/25 3:04 AM, Glavo wrote:
> * 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 was initially frustrated by the split between Java (AWT) and JavaFX in 
their image support and would have welcomed a common library, but I came 
to appreciate the flexibility of having both available in a JavaFX 
application. Below are some thoughts.

The challenge is not just in reading various external image formats. 
There are three parts:

 1. Efficiently loading and converting an image from an external format
    (GIF, PNG, JPG).
 2. Efficiently storing images internally with a minimal number of bits
    per pixel.
 3. Efficiently converting the internal format to that required by the
    client library (AWT, JavaFX, Android).

The first item is determined by the external image format standards, but 
the second and third items involve a trade-off. Optimizing for memory 
usage might results in a huge waste of CPU time doing conversions, while 
optimizing for zero conversion time might results in a huge waste of 
RAM. A JavaFX application can pick and choose between this trade-off by 
using both the AWT and JavaFX image libraries.

For example, I had to load and display hundreds of binary images (pure 
black and white) on a constrained device. The AWT can store images in 
memory as one bit per pixel, but JavaFX supports only 32-bit images. So 
I needed to use the AWT image format in memory, but the JavaFX image 
format for display, converting them on-the-fly one-by-one to 32 bits per 
pixel.

JavaFX provides an AWT-to-JavaFX image conversion utility, called 
SwingFXUtils::toFxImage 
<https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingFXUtils.java>, 
but I couldn't use it because it was far too slow. It's slow because 
it's generic and has to work for all image types. I came up with 14 
different ways to convert <https://github.com/jgneff/tofximage> an AWT 
image to a JavaFX image: 9 that work for images with transparency and 
another 5 that work only for images with no alpha. In my case, one such 
conversion was much faster than the others 
<https://jgneff.github.io/tofximage/2020-06/>.

A common library might end up too generic, too slow, or require too much 
memory to be useful.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250416/79916b99/attachment-0001.htm>

From angorya at openjdk.org  Wed Apr 16 19:40:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 19:40:49 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener [v2]
In-Reply-To: <c4FQjcKRSp0QEeWQnIYn3Y6DpCLWv5voXMpCAqVX8tk=.dc34a11e-15d1-45dd-a5eb-e3cb49d0605f@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
 <c4FQjcKRSp0QEeWQnIYn3Y6DpCLWv5voXMpCAqVX8tk=.dc34a11e-15d1-45dd-a5eb-e3cb49d0605f@github.com>
Message-ID: <_yxSVYXJKM9Taq3At6lIMQDmuroadLaEbfeXrgdfjUs=.bab3aec7-c31d-40bb-9757-53a84224022a@github.com>

On Wed, 16 Apr 2025 18:43:01 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.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into fixes/needslayout-wrong-value
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java
>  - fix
>  - failing test

I see no ill effects in the TableView.

Just to be on the safe side, I tried to re-create the scenario with the canvas-based cell and row factories in the monkey tester, and I did not see any issues.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1781#pullrequestreview-2773650906

From angorya at openjdk.org  Wed Apr 16 20:05:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:05:03 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest [v2]
In-Reply-To: <6gBk01gbOzcgJ1PABYapo8bE1Lz-Zd2O6vHPdMOyq0s=.631dd7a8-a8d6-4ec9-b114-4deb1536a28b@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <79K9NXxOwFi65KCP1-ZGTHvS_7Is_NaiNGU0JWvvtTg=.8442f221-a6b3-4127-9eb8-9045dbe29d14@github.com>
 <6gBk01gbOzcgJ1PABYapo8bE1Lz-Zd2O6vHPdMOyq0s=.631dd7a8-a8d6-4ec9-b114-4deb1536a28b@github.com>
Message-ID: <GupgcYK9cfT-Tn1R9g6nyFPhA_yusyjKZpLa0yZPT6I=.80a04fbe-b903-469b-b04e-866015677325@github.com>

On Wed, 16 Apr 2025 16:23:14 GMT, Kevin Rushforth <kcr 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>>  - 8088343
>
> modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java line 1021:
> 
>> 1019:                 switch (getState()) {
>> 1020:                 case FAILED:
>> 1021:                 case SUCCEEDED:
> 
> Avoiding transitioning from a one of the completion states to canceled is a good thing. My question, though is: how did we get here? Is this masking some other problem?

I think the variations in the test timing uncovered this issue.  I don't think it's a problem with the execution of the task, but rather with the reporting of its final state.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1769#discussion_r2047660750

From mstrauss at openjdk.org  Wed Apr 16 20:05:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 20:05:49 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
 <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>
Message-ID: <KJboHK30LXiqycI8ZA1-DhkHK-zh5nVt7S7pysKiNwg=.b087ff83-85e7-45ea-8014-31fd4cbaa40e@github.com>

On Wed, 16 Apr 2025 19:27:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > then have null mean "I want no overflow menu"
> 
> An interesting suggestion.
> 
> This would be a much larger change, since we would have to remove the button as well. Also, the `menuGraphicFactory` seems rather unrelated to the overflow menu button - an RFE with a boolean property might be better choice.
> 
> (you can probably tell I am against this idea ;-)

This doesn't need to be implemented now. I'm mainly suggesting that a default factory should not be a `null` value.

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2810631025

From angorya at openjdk.org  Wed Apr 16 20:13:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:13:43 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <KJboHK30LXiqycI8ZA1-DhkHK-zh5nVt7S7pysKiNwg=.b087ff83-85e7-45ea-8014-31fd4cbaa40e@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
 <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>
 <KJboHK30LXiqycI8ZA1-DhkHK-zh5nVt7S7pysKiNwg=.b087ff83-85e7-45ea-8014-31fd4cbaa40e@github.com>
Message-ID: <Fcna7Kg7wrhKpi4pZq8nYSklqwhr3qdKpwi4bXVROvI=.71f5d9f9-492e-4769-881d-92453fe301c3@github.com>

On Wed, 16 Apr 2025 20:03:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> default factory should not be a `null` value.

oh, I see.  I think it makes the life easier, since there is no need to publish the pointer to the deficient `DEFAULT_FACTORY`.

This property can be qualified with "override" to make it clearer (though longer).

`menyGraphicFactoryOverrideProperty`

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2810650953

From angorya at openjdk.org  Wed Apr 16 20:28:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:28:15 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest [v2]
In-Reply-To: <6gBk01gbOzcgJ1PABYapo8bE1Lz-Zd2O6vHPdMOyq0s=.631dd7a8-a8d6-4ec9-b114-4deb1536a28b@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <79K9NXxOwFi65KCP1-ZGTHvS_7Is_NaiNGU0JWvvtTg=.8442f221-a6b3-4127-9eb8-9045dbe29d14@github.com>
 <6gBk01gbOzcgJ1PABYapo8bE1Lz-Zd2O6vHPdMOyq0s=.631dd7a8-a8d6-4ec9-b114-4deb1536a28b@github.com>
Message-ID: <o6uiDIT_KufEeBdbt5MScO0NNeGHhtklujGnpDVG_fQ=.db55498e-931e-4eb5-943a-392dd8a7383b@github.com>

On Wed, 16 Apr 2025 16:35:39 GMT, Kevin Rushforth <kcr 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>>  - 8088343
>
> modules/javafx.graphics/src/main/java/javafx/concurrent/Task.java line 1041:
> 
>> 1039:                     }
>> 1040:                 });
>> 1041:                 return rv.get();
> 
> This is ineffective since you don't wait for the runLater to execute (and waiting could lead to deadlock, so I wouldn't recommend that). I don't think there is anything better than unconditionally returning `flag` when not running on the FX app thread. That's what the current code does (and is what your proposed fix will do most of the time).

good point!

In this particular case, returning `true` from `cancel()` when state will not be changed is acceptable.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1769#discussion_r2047689677

From angorya at openjdk.org  Wed Apr 16 20:28:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:28:14 GMT
Subject: RFR: 8088343: Intermittent unit test failure in
 javafx.concurrent.ServiceLifecycleTest [v3]
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: <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@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 five additional commits since the last revision:

 - cleanup
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
 - 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/d605fb92..66d2edb9

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

  Stats: 574 lines in 20 files changed: 204 ins; 200 del; 170 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  Wed Apr 16 20:28:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 20:28:47 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: <2u8tXDchGPxFHrvUXkXExzumAYHF48i41cGFe4Y5ARg=.14359c18-3c1c-456c-a128-5839fe53e7c9@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

The updated test looks good to me. I noted one unnecessary boxed primitive.

tests/system/src/test/java/test/robot/javafx/scene/MouseLocationOnScreenTest.java line 122:

> 120:      */
> 121:     static void validate(Robot robot, int x, int y) {
> 122:         Boolean equalValue = false;

There is no need to box the primitive in a `Boolean` object here:

`Boolean` --> `boolean`

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

PR Review: https://git.openjdk.org/jfx/pull/1772#pullrequestreview-2773255181
PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2047372227

From angorya at openjdk.org  Wed Apr 16 20:28:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:28:47 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v4]
In-Reply-To: <2u8tXDchGPxFHrvUXkXExzumAYHF48i41cGFe4Y5ARg=.14359c18-3c1c-456c-a128-5839fe53e7c9@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <UfrLAlwYe62iMHocx1ixWfwu6HyUGaOSjs8XT86JQDE=.312869f1-f99d-4e22-801e-b9bfcfcbc080@github.com>
 <2u8tXDchGPxFHrvUXkXExzumAYHF48i41cGFe4Y5ARg=.14359c18-3c1c-456c-a128-5839fe53e7c9@github.com>
Message-ID: <-jbwAoZYOO1eser7NOi1JNlgslKT98gYUF3DcJ3lOUQ=.e02f0093-96dc-4c4b-9866-1d38b34e8004@github.com>

On Wed, 16 Apr 2025 17:07:09 GMT, Kevin Rushforth <kcr 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 122:
> 
>> 120:      */
>> 121:     static void validate(Robot robot, int x, int y) {
>> 122:         Boolean equalValue = false;
> 
> There is no need to box the primitive in a `Boolean` object here:
> 
> `Boolean` --> `boolean`

`eagle-eye.png`!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1772#discussion_r2047694155

From angorya at openjdk.org  Wed Apr 16 20:34:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:34:47 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests
In-Reply-To: <vY9RFO_WW9smy9Uc4kiP4O3zWc0bL_5lgV1LBw27r5U=.ed635cf0-2f45-4ba0-a69e-593eb30bbf32@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <vY9RFO_WW9smy9Uc4kiP4O3zWc0bL_5lgV1LBw27r5U=.ed635cf0-2f45-4ba0-a69e-593eb30bbf32@github.com>
Message-ID: <2Ch61SGxljqw_HJfERQsmnLceqk2uHQ-_l04xT1ONVw=.cb749f02-f5d4-4858-bfa1-3049e7f3be6f@github.com>

On Wed, 16 Apr 2025 19:00:53 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Linux fails with `org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]` when creating the `Display`.

does it fail with `IS_FULL_TEST=true`?

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810699950

From mstrauss at openjdk.org  Wed Apr 16 20:44:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Apr 2025 20:44:49 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <Fcna7Kg7wrhKpi4pZq8nYSklqwhr3qdKpwi4bXVROvI=.71f5d9f9-492e-4769-881d-92453fe301c3@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
 <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>
 <KJboHK30LXiqycI8ZA1-DhkHK-zh5nVt7S7pysKiNwg=.b087ff83-85e7-45ea-8014-31fd4cbaa40e@github.com>
 <Fcna7Kg7wrhKpi4pZq8nYSklqwhr3qdKpwi4bXVROvI=.71f5d9f9-492e-4769-881d-92453fe301c3@github.com>
Message-ID: <WIWF5R1sDDKdXKup7np2p-3qqzUBGeFeQFwkF1F15nM=.ba9b3a6e-2bd6-4b2c-84f1-8622cf89c207@github.com>

On Wed, 16 Apr 2025 20:10:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > default factory should not be a `null` value.
> 
> oh, I see. I think it makes the life easier, since there is no need to publish the pointer to the deficient `DEFAULT_FACTORY`.
> 
> This property can be qualified with "override" to make it clearer (though longer).
> 
> `menyGraphicFactoryOverrideProperty`

On the other hand, if you have a `DEFAULT_FACTORY`, you also have an explicit API element to explain the behavior of the default factory, instead of rolling the documentation into `menuGraphicFactory`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2810722796

From angorya at openjdk.org  Wed Apr 16 20:58:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 20:58:59 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
Message-ID: <ah61U4KPyqHiKZjMG54BBl1e2D3gMIsRY5muL4lS7ZM=.1f5c64c3-5f98-4cbb-8963-0f80472bda6c@github.com>

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

> 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()"

modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 822:

> 820:         final ObservableList<String> styleClasses = detailsButton.getStyleClass();
> 821: 
> 822:         styleClasses.add("details-button");  //$NON-NLS-1$

do we use these `//$NON-NLS-1$` in jfx?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2047750714

From angorya at openjdk.org  Wed Apr 16 21:01:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 21:01:58 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
Message-ID: <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>

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

> 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()"

An SCCE would have been nice, to help with the review/testing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2810781835

From kcr at openjdk.org  Wed Apr 16 21:12:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 21:12:45 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <qXnXsTQ1zrXVKhNpkYat3yfQUFu-hFC9XdPoVmv7F78=.7b6604c7-2302-4225-9bea-2c2d7dc6ac36@github.com>

On Wed, 16 Apr 2025 18:48:09 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Note: At one point IS_FULL_TEST was used as well for the enablement of the tests. I don't see any reason for it.

All headful tests are qualified by `IS_FULL_TEST`, so this should remain here, too. We do the same thing when enabling robot tests, in that you still have to specify `-PFULL_TEST=true`.

build.gradle line 3085:

> 3083: 
> 3084:     test {
> 3085:         enabled = IS_SWT_TEST

These tests are not headless tests so they still need to be qualified by `IS_FULL_TEST`

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

PR Review: https://git.openjdk.org/jfx/pull/1783#pullrequestreview-2773758349
PR Review Comment: https://git.openjdk.org/jfx/pull/1783#discussion_r2047694060

From mhanl at openjdk.org  Wed Apr 16 21:17:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 21:17:16 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>

> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
> 
> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  8169285: SWT tests should run with IS_FULL_TEST

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1783/files
  - new: https://git.openjdk.org/jfx/pull/1783/files/16935f94..a99f75ae

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

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

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

From mhanl at openjdk.org  Wed Apr 16 21:17:17 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 16 Apr 2025 21:17:17 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <qXnXsTQ1zrXVKhNpkYat3yfQUFu-hFC9XdPoVmv7F78=.7b6604c7-2302-4225-9bea-2c2d7dc6ac36@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <qXnXsTQ1zrXVKhNpkYat3yfQUFu-hFC9XdPoVmv7F78=.7b6604c7-2302-4225-9bea-2c2d7dc6ac36@github.com>
Message-ID: <kXeA9a1LX4fmisgogvQPAnmrWM2Zb6xe2zRwYO_JZ7o=.7a30405f-15fd-4d89-b7f4-b4af21385bd8@github.com>

On Wed, 16 Apr 2025 20:26:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8169285: SWT tests should run with IS_FULL_TEST
>
> build.gradle line 3085:
> 
>> 3083: 
>> 3084:     test {
>> 3085:         enabled = IS_SWT_TEST
> 
> These tests are not headless tests so they still need to be qualified by `IS_FULL_TEST`

I tested that in another Branch and therefore GHA build and can confirm that as well! Linux is green with `IS_FULL_TEST`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1783#discussion_r2047770646

From kcr at openjdk.org  Wed Apr 16 21:24:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 21:24:44 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
Message-ID: <jvZ5AXD2UIKbWwGz3wojiEJdx-32JXIgm_Paa_beGkI=.837fe3c7-5052-479b-be65-7f18fd311a0e@github.com>

On Wed, 16 Apr 2025 21:17:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
>> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
>> 
>> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8169285: SWT tests should run with IS_FULL_TEST

I was curious as to why the tests were being run on GHA without your setting the `SWT_TEST` flag, and then spotted this in `build.gradle`, line 502:


// Specifies whether to run system tests that depend on SWT (only used when FULL_TEST is also enabled)
defineProperty("SWT_TEST", "true")


So even though we have a flag, it is on by default (which makes me wonder why we bothered with a flag). If the tests are stable, which will need to be tested (I can do a CI build tomorrow), we can leave it enabled by default, in which case the only flag you would need is `-PFULL_TEST=true`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810825722

From kcr at openjdk.org  Wed Apr 16 21:32:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 21:32:48 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <jvZ5AXD2UIKbWwGz3wojiEJdx-32JXIgm_Paa_beGkI=.837fe3c7-5052-479b-be65-7f18fd311a0e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <jvZ5AXD2UIKbWwGz3wojiEJdx-32JXIgm_Paa_beGkI=.837fe3c7-5052-479b-be65-7f18fd311a0e@github.com>
Message-ID: <6-zsDCOGk5aIYockQhxIHd_2WeN9BS9jX3a7uo0Qxlc=.2722f386-9108-4b66-9f2a-d1b03c3c4b3e@github.com>

On Wed, 16 Apr 2025 21:22:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> we can leave it enabled by default, in which case the only flag you would need is -PFULL_TEST=true.

I realize my statement might be ambiguous. I am not suggesting further changes to build.gradle: you can leave it as:


    enabled = IS_FULL_TEST && IS_SWT_TEST


What I meant is that developers will not need to explicitly set SWT_TEST=true since it already is by default.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810846122

From angorya at openjdk.org  Wed Apr 16 21:32:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 21:32:49 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
Message-ID: <T4J4XugrpYiAJxlWWNczcW1kd7PeiIki69Y9p84EnEk=.edd1057e-72f5-4395-961e-f6a2365e552b@github.com>

On Wed, 16 Apr 2025 21:17:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
>> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
>> 
>> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8169285: SWT tests should run with IS_FULL_TEST

yes, we still need `SWT_TEST` so we can disable it on mac.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810854365

From kcr at openjdk.org  Wed Apr 16 21:56:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 21:56:48 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <T4J4XugrpYiAJxlWWNczcW1kd7PeiIki69Y9p84EnEk=.edd1057e-72f5-4395-961e-f6a2365e552b@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <T4J4XugrpYiAJxlWWNczcW1kd7PeiIki69Y9p84EnEk=.edd1057e-72f5-4395-961e-f6a2365e552b@github.com>
Message-ID: <FXpYxplgjvpSNZ_iEtBsPGHPQVCKWSDtqI3LZSwBv4k=.02eb0abb-f3dd-41c0-aad0-0379b5306be6@github.com>

On Wed, 16 Apr 2025 21:30:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> yes, we still need `SWT_TEST` so we can disable it on mac.

If that flag is the mechanism we need to use to disable it on macOS, then we will need the following additional change:


 // Specifies whether to run system tests that depend on SWT (only used when FULL_TEST is also enabled)
-defineProperty("SWT_TEST", "true")
+defineProperty("SWT_TEST", IS_MAC ? "false" ? "true")
 ext.IS_SWT_TEST = Boolean.parseBoolean(SWT_TEST);

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810895455

From kcr at openjdk.org  Wed Apr 16 22:02:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Apr 2025 22:02:43 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <FXpYxplgjvpSNZ_iEtBsPGHPQVCKWSDtqI3LZSwBv4k=.02eb0abb-f3dd-41c0-aad0-0379b5306be6@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <T4J4XugrpYiAJxlWWNczcW1kd7PeiIki69Y9p84EnEk=.edd1057e-72f5-4395-961e-f6a2365e552b@github.com>
 <FXpYxplgjvpSNZ_iEtBsPGHPQVCKWSDtqI3LZSwBv4k=.02eb0abb-f3dd-41c0-aad0-0379b5306be6@github.com>
Message-ID: <ga1PlsRDqs7jl_gIHmZztdrcubRkTfLe8IEqOXZuGbY=.2e414c21-1fb4-4d20-9f80-5c15caf4e67d@github.com>

On Wed, 16 Apr 2025 21:51:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > yes, we still need `SWT_TEST` so we can disable it on mac.
> 
> If that flag is the mechanism we need to use to disable it on macOS, then we will need the following additional change:
> 
> ```
>  // Specifies whether to run system tests that depend on SWT (only used when FULL_TEST is also enabled)
> -defineProperty("SWT_TEST", "true")
> +defineProperty("SWT_TEST", IS_MAC ? "false" ? "true")
>  ext.IS_SWT_TEST = Boolean.parseBoolean(SWT_TEST);
> ```

Never mind. There is already this:


        if (IS_MAC) {
            enabled = false
            logger.info("SWT tests are disabled on MAC, because Gradle test runner does not handle -XstartOnFirstThread properly (https://issues.gradle.org/browse/GRADLE-3290).")
        }

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2810909886

From john.hendrikx at gmail.com  Wed Apr 16 23:13:15 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 17 Apr 2025 01:13:15 +0200
Subject: Unnecessary layouts; TLDR; new method "requestLocalLayout"
In-Reply-To: <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>
Message-ID: <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>

I tested this with several controls that were triggering layouts (like
on cursor movements), and I saw no adverse effects.? Basically, any time
you interact with a control and it triggers a full layout but its bounds
didn't change (ie. nothing in the UI changed position or size) the full
layout was unnecessary.

Most Skins/Controls do the simple thing of registering listeners on any
properties that may change their appearance and calling requestLayout,
while calling requestLayout should really be reserved for things that
change their computeMin/Pref/Max values. If there were no changes in any
of those, then the parent layout won't have changes either (and so on)
so the final layout result will be the exact same as before, yet tens of
thousands of calculations will have been done.? Because of how say HBox
calculates its size, it also queries any siblings, which in turn may be
containers...

The only things "stopping" layout propagation are things like scroll
panes.? This is why TextArea is a lot less likely to trigger a layout
all the way to the root vs TextField.

--John

On 16/04/2025 17:04, Nir Lisker wrote:
> 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/20250417/ea9151b5/attachment.htm>

From jhendrikx at openjdk.org  Wed Apr 16 23:29:44 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Apr 2025 23:29:44 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
Message-ID: <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>

On Wed, 16 Apr 2025 20:59:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> An SCCE would have been nice, to help with the review/testing.
> 
> edit: alternatively, I'll add the (missing) Dialog/DialogPane page to the monkey tester. ??

If you still need one, I can provide a bit of code.  It basically is just changing the hyperlink style, and then seeing it doesn't affect the Alert dialog when it has an extended area.  After the change, it should affect it.  I did include a screenshot -- I may find more of these bugs as I continue developing with modena.css with dark theme colors :)

> modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 822:
> 
>> 820:         final ObservableList<String> styleClasses = detailsButton.getStyleClass();
>> 821: 
>> 822:         styleClasses.add("details-button");  //$NON-NLS-1$
> 
> do we use these `//$NON-NLS-1$` in jfx?

I do not know if we do, as there is also non-public code that I don't have access to.  I've kept them as-is to make sure the change is focused and doesn't break anything else.

If I had to guess then probably not, if you can ask around and find out I'll be happy to remove them.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2811089058
PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2047923713

From angorya at openjdk.org  Wed Apr 16 23:32:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Apr 2025 23:32:48 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
 <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>
Message-ID: <30v2JmZmU-Qr-KcD51smWwzs4GxKWdl3qjM_oPT5gBE=.8fbce58b-82af-4d26-8a35-13570547b2c8@github.com>

On Wed, 16 Apr 2025 23:27:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> If you still need one, I can provide a bit of code.

Thanks, that's ok, I would rather add the Dialog page to the MT, as it will allow for more extensive testing.

>> modules/javafx.controls/src/main/java/javafx/scene/control/DialogPane.java line 822:
>> 
>>> 820:         final ObservableList<String> styleClasses = detailsButton.getStyleClass();
>>> 821: 
>>> 822:         styleClasses.add("details-button");  //$NON-NLS-1$
>> 
>> do we use these `//$NON-NLS-1$` in jfx?
>
> I do not know if we do, as there is also non-public code that I don't have access to.  I've kept them as-is to make sure the change is focused and doesn't break anything else.
> 
> If I had to guess then probably not, if you can ask around and find out I'll be happy to remove them.

I'll double check and will let you know tomorrow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2811093389
PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2047928744

From jhendrikx at openjdk.org  Thu Apr 17 00:07:44 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 17 Apr 2025 00:07:44 GMT
Subject: RFR: 8354813: Parent.isNeedsLayout() may return wrong value in
 property listener [v2]
In-Reply-To: <c4FQjcKRSp0QEeWQnIYn3Y6DpCLWv5voXMpCAqVX8tk=.dc34a11e-15d1-45dd-a5eb-e3cb49d0605f@github.com>
References: <Poli4vZ_iRRqVQxfGCtbVq4_hq-6H_p6RSUXOATqdVk=.06eac4ab-db44-4011-b740-7df2076a1daa@github.com>
 <c4FQjcKRSp0QEeWQnIYn3Y6DpCLWv5voXMpCAqVX8tk=.dc34a11e-15d1-45dd-a5eb-e3cb49d0605f@github.com>
Message-ID: <vO1pwmexn-kz6Af9fTYSwV_1sSb0U071h0KIatP8p8Q=.044f287e-b0a7-48e3-989c-a4b63bceabad@github.com>

On Wed, 16 Apr 2025 18:43:01 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.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into fixes/needslayout-wrong-value
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java
>  - fix
>  - failing test

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1781#pullrequestreview-2774167347

From philip.race at oracle.com  Thu Apr 17 04:09:59 2025
From: philip.race at oracle.com (Philip Race)
Date: Wed, 16 Apr 2025 21:09:59 -0700
Subject: Proposal: A new common Image API
In-Reply-To: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
Message-ID: <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>

First, note than John Neffenger replied to this but only on openjfx-dev
and the first thing I saw was the reply and couldn't see the original.
After some consternation I tracked down this cross-post.

Here's a link to the reply 
https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html

A fundamental problem is that all the users need to be able to produce 
and consume the data.
So there either needs to be a module dependency (not viable) or an 
agreed format (are we
really going to define an image format which encapsulates everything, 
including the multi-frame
GIF support) and then everyone needs a reader and don't forget writers 
and they need to be able to do .. so much ..

I just don't see a viable path here.
And several (8 ?) years ago, I pondered some way to separate image 
handling from the
desktop module to see if a server app could use it without pulling in 
AWT but the intra-package
dependencies made it impossible without changes I didn't even figure out 
if they were possible.

-phil.

On 4/16/25 3:04 AM, Glavo wrote:
> 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
>


From duke at openjdk.org  Thu Apr 17 05:57:12 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Thu, 17 Apr 2025 05:57:12 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v5]
In-Reply-To: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
Message-ID: <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@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/74dbbb4a..4e3e1dfe

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 mstrauss at openjdk.org  Thu Apr 17 07:32:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Apr 2025 07:32:58 GMT
Subject: Integrated: 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: <xCZ5WYKNpxYiqd3JzlG9BEhqxWHwRgBnCvgNz-1XgNI=.f0ddefdb-1aee-42ba-ac1c-d7ee2a9ebc30@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.

This pull request has now been integrated.

Changeset: 9291099c
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9291099cc3a7830937bffdb65100b372ea1cc77a
Stats:     28 lines in 3 files changed: 26 ins; 1 del; 1 mod

8354813: Parent.isNeedsLayout() may return wrong value in property listener

Reviewed-by: jhendrikx, angorya

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

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

From arapte at openjdk.org  Thu Apr 17 08:42:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 17 Apr 2025 08:42:58 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: <OuUmFfDwn3Olv_llukuJUAZL4Or94zE2PPQ7Z8uEmWo=.86ebe738-570f-48d0-bf1b-58b204dd2d63@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.

Change looks good, I could verify that the issue reproduces without this change and gets fixed with this change.
Sanity testing looks good.
Providing couple minor renaming suggestions.

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.h line 97:

> 95:     BYTE *header;
> 96:     gsize header_size;
> 97:     gboolean send_header;

may be rename as `is_send_header` similar to the other boolean variables of the class.

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.h line 108:

> 106:     guint pixel_den;
> 107: 
> 108:     gboolean set_caps;

may be rename as `is_set_caps` similar to the other boolean variables of the class.

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

PR Review: https://git.openjdk.org/jfx/pull/1775#pullrequestreview-2775016635
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2048505039
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2048505649

From tsayao at openjdk.org  Thu Apr 17 11:51:06 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 17 Apr 2025 11:51:06 GMT
Subject: Withdrawn: 8354480: A Stage should allow simultaneous iconified and
 maximized states
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: <3QlGCq5rdQQn58fTR1RPR5nvrv9qv9IC7bdNd2P8ZSI=.f41f884a-31cf-4407-8a79-859d1fa6e57a@github.com>

On Sun, 13 Apr 2025 17:46:58 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.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Apr 17 14:21:48 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 17 Apr 2025 14:21:48 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: <Bz1Ik8xVm6MHm1cU4UyJlZItgz_gOZUwYSjL7gUilIg=.2ac0d9a1-a61f-4450-8a59-e985b60f1ce9@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 refactored the test repository to make more transparent which version is used and how it is build.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2813104910

From duke at openjdk.org  Thu Apr 17 14:21:49 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 17 Apr 2025 14:21:49 GMT
Subject: RFR: 8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not
 receiving events
In-Reply-To: <u6mKab7iDb7z0tjOvlpySRNGtgDGJ7qiWlxdM8TJApU=.929e71a9-57c7-40a4-8734-8472d5131d75@github.com>
References: <Kr-LgvCVMhJdiXxTIdTkg7fAnyFrx_WLjvAqpMZGgeQ=.b6382590-f6d4-47a6-832b-67eafbb69a39@github.com>
 <hN-MD-vBR5nHpvTMwtu5g5QitdKoN65RWOGdvJKEAUo=.c5c0e09f-c529-447f-81f2-367e0f3071f5@github.com>
 <u6mKab7iDb7z0tjOvlpySRNGtgDGJ7qiWlxdM8TJApU=.929e71a9-57c7-40a4-8734-8472d5131d75@github.com>
Message-ID: <Ce2QxiPlXrpzK1Rq4DoCCq2AF6SlTRULscj6IusnBvw=.6d3738ab-543e-4c77-b6c6-b9c752415249@github.com>

On Mon, 14 Apr 2025 21:39:48 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 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.
>
>> 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

@kevinrushforth could You please take a look again now?

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2813106296

From angorya at openjdk.org  Thu Apr 17 14:29:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 14:29:49 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v5]
In-Reply-To: <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
Message-ID: <CUIhBWx7ZsuVSgJfEUjC74zSgUoLXHyJMEwAjYOPjh4=.c02f088c-97ea-4086-afb7-b5f0b1e5c3dd@github.com>

On Thu, 17 Apr 2025 05:57: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.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

thank you for the fix and addressing the comments!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1772#pullrequestreview-2775980857

From kcr at openjdk.org  Thu Apr 17 14:57:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Apr 2025 14:57:50 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v5]
In-Reply-To: <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
Message-ID: <6OAXiV37MaIYdxIxZaGZtOSoPVpqO-7zRLQ53l3grCM=.9702a947-de11-4f7e-83d5-693de884a4c1@github.com>

On Thu, 17 Apr 2025 05:57: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.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1772#pullrequestreview-2776063033

From kcr at openjdk.org  Thu Apr 17 15:16:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Apr 2025 15:16:51 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: <j_ahRzLTFFZRpY39ZgF-6VnNBawcYXQ02W6SVGVz3PE=.7375b80c-28db-410c-a56d-028d845c402f@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.

I left a few questions on the code changes. I haven't tested it yet.

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 259:

> 257:     // pDecoderOutput is released.
> 258:     SafeRelease(&decoder->pDecoderOutput);
> 259:     decoder->pDecoderBuffer = NULL;

Is setting this to NULL sufficient or does it need to be freed / released first?

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 267:

> 265:         // pColorConvertOutput is released.
> 266:         SafeRelease(&decoder->pColorConvertOutput[i]);
> 267:         decoder->pColorConvertBuffer[i] = NULL;

Is setting this to NULL sufficient or does it need to be freed / released first?

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1107:

> 1105:         {
> 1106:             SafeRelease(&decoder->pColorConvertOutput[i]);
> 1107:             decoder->pColorConvertBuffer[i] = NULL;

Same question as above.

modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1574:

> 1572:                                      g_strdup("Failed to reload decoder"), NULL,
> 1573:                                      ("mfwrapper.c"), ("mfwrapper_sink_event"), 0);
> 1574:             }

Is this a fatal error? If so, do you need to return early here?

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

PR Review: https://git.openjdk.org/jfx/pull/1775#pullrequestreview-2776106535
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2049156892
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2049157580
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2049164737
PR Review Comment: https://git.openjdk.org/jfx/pull/1775#discussion_r2049172358

From angorya at openjdk.org  Thu Apr 17 16:02:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 16:02:12 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
Message-ID: <8g-GPgnoX8X60Z-ms0HaqxJxuRsb2gTyAI2ht30B_fo=.9bf1a49c-4ec1-400e-9947-a446a6fbabad@github.com>

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

> 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()"

I've added the Dialog page to the monkey tester
https://github.com/andy-goryachev-oracle/MonkeyTest

Looking at the stock behavior, I don't really see the problem.  The .details-button should not _look_ a hyperlink (despite being implemented using Hyperlink control), so the code seems to be correct in that it replaces the hyperlink style with something else.

What we probably need for the dark mode is to update the stylesheet as you described in the ticket.

What do you think?

![Screenshot 2025-04-17 at 08 59 10](https://github.com/user-attachments/assets/d9536f3b-d1bc-4f4f-8803-d003f2bd411c)

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813427379
PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813429506

From angorya at openjdk.org  Thu Apr 17 16:08:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 16:08:00 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property
In-Reply-To: <WIWF5R1sDDKdXKup7np2p-3qqzUBGeFeQFwkF1F15nM=.ba9b3a6e-2bd6-4b2c-84f1-8622cf89c207@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <JQGoVoeexZHaOOlupaO7XU1Zhoz_PlBmRCce2LY1h-4=.58f723ba-08f8-4cc8-91bb-27beca9ef39b@github.com>
 <rgmdMwtenMX8LfB01bGOdzozVmCQqx3ku8QZlAdRyNA=.a9b06bf6-bc04-4549-871c-9396553de3c3@github.com>
 <KJboHK30LXiqycI8ZA1-DhkHK-zh5nVt7S7pysKiNwg=.b087ff83-85e7-45ea-8014-31fd4cbaa40e@github.com>
 <Fcna7Kg7wrhKpi4pZq8nYSklqwhr3qdKpwi4bXVROvI=.71f5d9f9-492e-4769-881d-92453fe301c3@github.com>
 <WIWF5R1sDDKdXKup7np2p-3qqzUBGeFeQFwkF1F15nM=.ba9b3a6e-2bd6-4b2c-84f1-8622cf89c207@github.com>
Message-ID: <envHEaefEhXBszTxxoomMzsopBoN1r8dxoYyHJ-WChE=.dd461b5f-1403-4ccc-af38-94428f32895f@github.com>

On Wed, 16 Apr 2025 20:41:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> if you have a `DEFAULT_FACTORY`, you also have an explicit API element to explain the behavior of the default factory, instead of rolling the documentation into `menuGraphicFactory`.

I would rather not do that - it feels like we should not be elevating a sub-optimal implementation to the rank of a new public API here.  There is nothing to gain in having an instance of the default factory, in my opinion.

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2813442091

From kcr at openjdk.org  Thu Apr 17 16:23:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Apr 2025 16:23:51 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: <KtWd9IvbQuMMFO_S8IYRRSj_3KtQcj6Vphkq9U2vD6I=.39c06053-8c69-498a-a3ef-911948c0e2d7@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.

Testing looks good. I'll approve after you've had a chance to answer the outstanding questions.

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

PR Comment: https://git.openjdk.org/jfx/pull/1775#issuecomment-2813475615

From angorya at openjdk.org  Thu Apr 17 16:43:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 16:43:37 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v2]
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <Cn4HF7k19uEQvc87CMmoellqid5BxkMOaCwSJnly16E=.dabf462f-74b0-4123-86d0-7a685f689693@github.com>

> Tries to address the mystery of missing graphic in the TabPane overflow menu.
> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java
> 
> # Overflow Menu Graphic Property in the TabPaneSkin
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
> 
> 
> 
> ## Goals
> 
> The goals of this proposal are:
> 
> - to allow the application developers to customize the overflow menu items' graphic
> - retain the backward compatibility with the existing application code
> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - disable the overflow menu
> - configure overflow menu graphic property via CSS
> - add this property to the `TabPane` control itself
> 
> 
> 
> ## Motivation
> 
> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
> an `ImageView` or `Label` with an `ImageView`.
> 
> This limitation makes it impossible for the application developer to use other graphic Nodes,
> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
> when the tabs in the `TabPane` have no text.
> 
> Example:
> 
> 
> public class TabPaneGraphicFactoryExample {
>     public void example() {
>         Tab tab1 = new Tab("Tab1");
>         tab1.setGraphic(createGraphic(tab1));
> 
>         Tab tab2 = new Tab("Tab2");
>         tab2.setGraphic(createGraphic(tab2));
> 
>         TabPane tabPane = new TabPane();
>         tabPane.getTabs().addAll(tab1, tab2);
> 
>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>         // set overflow menu factory with the same method as was used to create the tabs
>         skin.setMenuGraphicFactory(this::createGraphic);
>         tabPane.setSkin(skin);
>     }
> 
>     // creates graphic Nodes for tabs as well as the overflow menu
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2":
>             return new Canvas(10, 10);
>         default:
>             return null;
>         }
>     }
> }
> 
> 
> 
> ## Description
> 
> The proposed solution adds the `menuGraphicFactory` property in the `TabPaneSkin` class:
> 
> 
>     /**
>      * This property allows to control the graphic for the overflow menu items,
>      * by genera...

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:

 - popup menu on demand
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - graphic factory

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/e50a550a..7cb4fa8e

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

  Stats: 472 lines in 15 files changed: 162 ins; 173 del; 137 mod
  Patch: https://git.openjdk.org/jfx/pull/1773.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1773/head:pull/1773

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

From swpalmer at gmail.com  Thu Apr 17 16:57:17 2025
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 17 Apr 2025 12:57:17 -0400
Subject: Proposal: A new common Image API
In-Reply-To: <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
Message-ID: <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>

I think a common image I/O library that is not tied to a UI framework makes
sense and is long overdue.
Raster images do have a common format that encapsulates everything. We
essentially have this abstracted in the two UI frameworks already. At some
level it comes down to PixelFormats and data buffers.  There are not so
many of them that it is impossible to make a common abstraction for the
purposes of I/O that can be mapped to what is needed by the UI framework.
Just as JavaFX already has the SwingFxUtils for converting between AWT and
JavaFX formats, there can be a utility to convert between the I/O library
format and each UI framework's format. I would expect in most cases that
the raw pixel data could be shared without extra copying.
ImageIO is a good starting point. Remove the actual UI classes from it like
BufferedImage and keep plain raster representations of the data that can be
wrapped by the UI classes.  Under the hood the arrays or buffers of raster
data don't have to change,they are the important parts that the I/O
library needs to deal with.  Mapping the metadata (width, height, colour
space, pixel format, etc.) will usually be very cheap. Some cases may need
to run a conversion, like the example of 1-bpp black/white needing to be
remapped to RGB, but that that can happen in the utility layer that moves
the image from the Image I/O domain to the UI framework domain on a
case-by-case basis. Worst case is that the UI framework throws an
UnsupportImageFormat exception when it doesn't have code to deal with
raster data in a particular format.

I'm sure it is all much harder than I suspect, but I don't think it should
be. :-)

Scott


On Thu, Apr 17, 2025 at 12:10?AM Philip Race <philip.race at oracle.com> wrote:

> First, note than John Neffenger replied to this but only on openjfx-dev
> and the first thing I saw was the reply and couldn't see the original.
> After some consternation I tracked down this cross-post.
>
> Here's a link to the reply
> https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html
>
> A fundamental problem is that all the users need to be able to produce
> and consume the data.
> So there either needs to be a module dependency (not viable) or an
> agreed format (are we
> really going to define an image format which encapsulates everything,
> including the multi-frame
> GIF support) and then everyone needs a reader and don't forget writers
> and they need to be able to do .. so much ..
>
> I just don't see a viable path here.
> And several (8 ?) years ago, I pondered some way to separate image
> handling from the
> desktop module to see if a server app could use it without pulling in
> AWT but the intra-package
> dependencies made it impossible without changes I didn't even figure out
> if they were possible.
>
> -phil.
>
> On 4/16/25 3:04 AM, Glavo wrote:
> > 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/20250417/23655c04/attachment.htm>

From andy.goryachev at oracle.com  Thu Apr 17 18:00:54 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 17 Apr 2025 18:00:54 +0000
Subject: [External] : Re: Unnecessary layouts; TLDR; new method
 "requestLocalLayout"
In-Reply-To: <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>
 <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>
Message-ID: <BYAPR10MB30131A2E47D9EC11E17AD8D0E5BC2@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you, this explanation ( https://bugs.openjdk.org/browse/JDK-8354801?focusedId=14770935&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14770935 ) makes a lot of sense.

What happens when the Parent decides it does need to change its bounds after all as a result of requestLayoutChildren()? Wouldn't this necessitate requestLayout()/requestParentLayout() so we end up with multiple pulses and resulting flicker?

-andy


From: John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, April 16, 2025 at 16:13
To: Nir Lisker <nlisker at gmail.com>, Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Unnecessary layouts; TLDR; new method "requestLocalLayout"

I tested this with several controls that were triggering layouts (like on cursor movements), and I saw no adverse effects.  Basically, any time you interact with a control and it triggers a full layout but its bounds didn't change (ie. nothing in the UI changed position or size) the full layout was unnecessary.

Most Skins/Controls do the simple thing of registering listeners on any properties that may change their appearance and calling requestLayout, while calling requestLayout should really be reserved for things that change their computeMin/Pref/Max values. If there were no changes in any of those, then the parent layout won't have changes either (and so on) so the final layout result will be the exact same as before, yet tens of thousands of calculations will have been done.  Because of how say HBox calculates its size, it also queries any siblings, which in turn may be containers...

The only things "stopping" layout propagation are things like scroll panes.  This is why TextArea is a lot less likely to trigger a layout all the way to the root vs TextField.

--John
On 16/04/2025 17:04, Nir Lisker wrote:
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<mailto: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<mailto:openjfx-dev-retn at openjdk.org>> on behalf of John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>>
Date: Monday, April 14, 2025 at 08:56
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto: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/20250417/c3a36c3f/attachment-0001.htm>

From angorya at openjdk.org  Thu Apr 17 18:12:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 18:12:57 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: <h89b6Wr-s9Z27e17mAWsYeg3AdgNfRT8gdZqATVBN0M=.5dc00c39-b1d2-4315-847e-b607e2887083@github.com>

On Wed, 16 Apr 2025 08:31:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> close those tickets?

both tickets are a duplicate of https://bugs.openjdk.org/browse/JDK-8264061 fixed in jfx17, closed both.  thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2813698480

From johan.vos at gluonhq.com  Thu Apr 17 18:34:41 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 17 Apr 2025 20:34:41 +0200
Subject: Proposal: A new common Image API
In-Reply-To: <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
 <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
Message-ID: <CABxFH2F+E9J5iE6v9mrw+zMeOMcC705rfwrNWbaxV9eVgX+jwQ@mail.gmail.com>

I started replying to this a couple of times, but I never finished it,
because
1) there are many different angles to look at the question
2) I believe it is indeed pretty hard.

However, I absolutely understand the original question, and I support the
idea. The fragmentation of "image" handling is a pain for many developers,
and it doesn't help the adoption of JavaFX (or AWT). Realistically, I
believe that in order to fix this issue, a considerable investment
(resources) is needed, and even then it will take a long time.

I think we can only talk about those AWT/JavaFX, and not about Android.
While the OpenJDK and OpenJFX process is relatively open (with a high
technical barrier, for good reasons) and allows for participation from
different companies, organisations and individuals, the Android process is
a different beast and I believe the chances that anyone on that side is
interested in my opinion are close to 0. That is one of the reasons why I'm
working on OpenJDK/Mobile, as that allows to run the real Java on Android
devices (basically, this is close to running Android on embedded linux
systems). We have JavaFX working on Android, so the JavaFX image API's work
on Android-devices. For those not familiar with OpenJDK/Mobile and the way
we do things at Gluon: we bundle Java application code and dependencies
with a hotspot-based JVM which is contained in a native library for
Android, and which can then be invoked from a plain Android Activity. We
have cross-compiled versions of the JavaFX libraries (including the imageio
libs) for Android, so those can be used.
While this is technically feasible (and I can address the typical critics
about footprint size and performance), this is not mainstream. Given the
enormous marketing power of Android versus the very limited resources we
have, this is not surprising, and I don't think we should discuss this in
this thread.

A common image API needs an API and implementations. John made excellent
points about the required flexibility of the API [1] (e.g. allow for a
trade-off between memory and performance). A good API allows developers to
deal with this, and we are far from there. Today, you actually need to look
at the implementation if you want to understand what is happening, and what
the impact is on CPU/memory. Handling this requires excellent API design,
lots of discussions with different actors and different usecases. This is
absolutely doable, but it is a major effort.

The other thing is the native, platform-specific implementation. This is
where the AWT parts and the JavaFX parts are conflicting. I don't recall
the exact place, but when creating static builds of the AWT libraries and
the JavaFX libraries on Linux, there were duplicate symbols, delivered by 2
different sources. It is not simply supporting different platforms, as
there are a number of partially overlapping and partially conflicting
low-level libraries for different formats/operations. JavaFX and
java.desktop don't have the exact same set of requirements for this.
This is something I ran into as well while working on building OpenJFX
using the OpenJDK build system [2] (although it is not really problematic
in this case, as we have 2 separate shared libs (1 for AWT and 1 for
JavaFX) that do not need to be combined into a single executable). Both
OpenJDK and OpenJFX contain a local version of libjpeg, but with a
different version. In OpenJDK, you can build using a system-provided
version of libjpeg. In order to have a single image API, those issues need
to be fixed and the approach needs to be streamlined.
One of the hard things in that case is, as Phil mentioned [3] that the
java.desktop module is not internally modular. It would require precision
surgery to separate the native dependencies required for image handling
only from the rest of the module. With an open and honest blog post from
Amy Fowler about Swing/AWT versus JavaFX in mind [4] (15 years ago!), I
assumed that, contrary to all other modules in openjdk, an internal cleanup
of java.desktop was not high priority, given the suggested path for UI
development in Java. My personal opinion here is that I'm not really sure a
new image API needs to be backward compatible with java.desktop, and it
would make it easier if it was targeting JavaFX only.

In summary, I absolutely support the idea of a new (common) image API. I
see a number of challenges in different sub-parts (API design, native code
integration between OpenJDK and OpenJFX), but I don't think I see technical
showstoppers. The amount of work to do this properly, in a maintainable
way, with the quality one expects from OpenJDK projects, should not be
underestimated though.

- Johan

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053661.html
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/053076.html
[3] https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053686.html
[4]
https://amyfowlersblog.wordpress.com/2010/09/21/a-heartfelt-ramble-on-swing-javafx/

On Thu, Apr 17, 2025 at 6:58?PM Scott Palmer <swpalmer at gmail.com> wrote:

> I think a common image I/O library that is not tied to a UI
> framework makes sense and is long overdue.
> Raster images do have a common format that encapsulates everything. We
> essentially have this abstracted in the two UI frameworks already. At some
> level it comes down to PixelFormats and data buffers.  There are not so
> many of them that it is impossible to make a common abstraction for the
> purposes of I/O that can be mapped to what is needed by the UI framework.
> Just as JavaFX already has the SwingFxUtils for converting between AWT and
> JavaFX formats, there can be a utility to convert between the I/O library
> format and each UI framework's format. I would expect in most cases that
> the raw pixel data could be shared without extra copying.
> ImageIO is a good starting point. Remove the actual UI classes from it
> like BufferedImage and keep plain raster representations of the data that
> can be wrapped by the UI classes.  Under the hood the arrays or buffers of
> raster data don't have to change,they are the important parts that the I/O
> library needs to deal with.  Mapping the metadata (width, height, colour
> space, pixel format, etc.) will usually be very cheap. Some cases may need
> to run a conversion, like the example of 1-bpp black/white needing to be
> remapped to RGB, but that that can happen in the utility layer that moves
> the image from the Image I/O domain to the UI framework domain on a
> case-by-case basis. Worst case is that the UI framework throws an
> UnsupportImageFormat exception when it doesn't have code to deal with
> raster data in a particular format.
>
> I'm sure it is all much harder than I suspect, but I don't think it should
> be. :-)
>
> Scott
>
>
> On Thu, Apr 17, 2025 at 12:10?AM Philip Race <philip.race at oracle.com>
> wrote:
>
>> First, note than John Neffenger replied to this but only on openjfx-dev
>> and the first thing I saw was the reply and couldn't see the original.
>> After some consternation I tracked down this cross-post.
>>
>> Here's a link to the reply
>> https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html
>>
>> A fundamental problem is that all the users need to be able to produce
>> and consume the data.
>> So there either needs to be a module dependency (not viable) or an
>> agreed format (are we
>> really going to define an image format which encapsulates everything,
>> including the multi-frame
>> GIF support) and then everyone needs a reader and don't forget writers
>> and they need to be able to do .. so much ..
>>
>> I just don't see a viable path here.
>> And several (8 ?) years ago, I pondered some way to separate image
>> handling from the
>> desktop module to see if a server app could use it without pulling in
>> AWT but the intra-package
>> dependencies made it impossible without changes I didn't even figure out
>> if they were possible.
>>
>> -phil.
>>
>> On 4/16/25 3:04 AM, Glavo wrote:
>> > 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/20250417/9a21084b/attachment-0001.htm>

From mhanl at openjdk.org  Thu Apr 17 18:58:46 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 17 Apr 2025 18:58:46 GMT
Subject: RFR: 8354702: [TestBug] LocalDateTimeStringConverterTest
 Workaround can be removed
In-Reply-To: <h89b6Wr-s9Z27e17mAWsYeg3AdgNfRT8gdZqATVBN0M=.5dc00c39-b1d2-4315-847e-b607e2887083@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>
 <h89b6Wr-s9Z27e17mAWsYeg3AdgNfRT8gdZqATVBN0M=.5dc00c39-b1d2-4315-847e-b607e2887083@github.com>
Message-ID: <SJsEf0vwLPC02JoH8m30Uu0Ge09ZQge4HYYt4HOe3eI=.791e3266-22b1-4fe2-963a-edf48db9e46d@github.com>

On Thu, 17 Apr 2025 18:09:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> both tickets are a duplicate of https://bugs.openjdk.org/browse/JDK-8264061 fixed in jfx17, closed both. thanks!

I don't want to close them when I was just testing them! So thank you for validating both tickets! :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1778#issuecomment-2813782930

From jhendrikx at openjdk.org  Thu Apr 17 19:21:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 17 Apr 2025 19:21:59 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <8g-GPgnoX8X60Z-ms0HaqxJxuRsb2gTyAI2ht30B_fo=.9bf1a49c-4ec1-400e-9947-a446a6fbabad@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <8g-GPgnoX8X60Z-ms0HaqxJxuRsb2gTyAI2ht30B_fo=.9bf1a49c-4ec1-400e-9947-a446a6fbabad@github.com>
Message-ID: <wcsuxWJpezTBoBoMPEaEh4CZ_p1ns1wdu9N_hhj32zs=.2c7221e8-9fb8-4788-b422-539644b7b27c@github.com>

On Thu, 17 Apr 2025 15:58:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I've added the Dialog page to the monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest
> 
> Looking at the stock behavior, I don't really see the problem. The .details-button should not _look_ a hyperlink (despite being implemented using Hyperlink control), so the code seems to be correct in that it replaces the hyperlink style with something else.
> 
> What we probably need for the dark mode is to update the stylesheet as you described in the ticket.
> 
> What do you think?

I think it _should_ look like a hyperlink, as the choices of potential clickable controls that users will recognize as such is limited; it can be either a button, checkbox or hyperlink.  You can't just define something new and expect users to understand it at a glance; and why even do so for an alert dialog?  This is clearly intended to mimic other standard alert dialogs that use the same kind of button to display details.

There are so many things dependent on the base style in modena, not having a base style is highly unusual and in this case IMHO a clear mistake in how the styles are being applied.  It just wasn't caught in testing as the default color matches close enough, but becomes rather obvious when changing the base colors significantly.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813824295

From angorya at openjdk.org  Thu Apr 17 19:56:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 19:56:52 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <wcsuxWJpezTBoBoMPEaEh4CZ_p1ns1wdu9N_hhj32zs=.2c7221e8-9fb8-4788-b422-539644b7b27c@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <8g-GPgnoX8X60Z-ms0HaqxJxuRsb2gTyAI2ht30B_fo=.9bf1a49c-4ec1-400e-9947-a446a6fbabad@github.com>
 <wcsuxWJpezTBoBoMPEaEh4CZ_p1ns1wdu9N_hhj32zs=.2c7221e8-9fb8-4788-b422-539644b7b27c@github.com>
Message-ID: <048_ktSVHxZjgpRJ5uHCq0wZlvZqko2jGPyZrIXx4zw=.0cc1b279-9de8-495b-b3d9-5092339eb84d@github.com>

On Thu, 17 Apr 2025 19:19:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I think it _should_ look like a hyperlink

It might look like a hyperlink, but it has a different semantics (semantics of a hyperlink is to navigate to some other place).   When application wants to change the hyperlink styling, we don't want this to propagate to unrelated controls such as dialog buttons, or we get this:

https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExN29yNmd3dGRlNW0wNXMxaWpmM25pdTUyOGZrcmV1dm9oemFkaWZucSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/13FrpeVH09Zrb2/giphy.gif

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813883738

From jhendrikx at openjdk.org  Thu Apr 17 20:14:56 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 17 Apr 2025 20:14:56 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
Message-ID: <N5zOjUcitnwwALQuB0yppdefTr4bmOyREZpr5gjRZTs=.379214cb-ba52-4d0f-908a-fbd43c302f84@github.com>

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

> 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()"

In Windows, and also our color chooser, hyperlinks are used with some regularity to avoid a button where it would look out of place -- in small windows, buttons often are seen as a "closing" action, which show details clearly is not intended to be.  The Windows copy dialog for example has a show details text that's clickable, and when keyboard focused displays the classic hyperlink dashed rectangular border.

I've looked in FX code, and wiping out the base style is AFAICS not done anywhere.  There are of course many cases of `getStyleClass().setAll( ... )` but all of the ones I checked do this on non-Controls (StackPane most often).  The big difference here is that such containers like StackPane don't have a default style so there is nothing that would be overwritten.  Only controls have these, and wiping it out is, and I'm repeating myself, highly unusual as it will kill many lines of default styling in modena leaving you to have to repeat all those lines.  That didn't happen, and neither was this code commented as "intentionally removing the default style class for this control".

If this indeed was the intent, then it would have made **much** more sense to not wipe out the base style, and only make adjustments specifically for hyperlinks that are also styled with `.details-button`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813924443

From martinfox656 at gmail.com  Thu Apr 17 20:24:38 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 17 Apr 2025 13:24:38 -0700
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@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>
 <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@mail.gmail.com>
Message-ID: <E6B4F323-F26B-479C-A279-0373C9B76125@gmail.com>

Christopher,

Why are you trying to change the size of a maximized stage? I?m not sure what the intended effect is.

Currently this produces all sort of platform-specific behavior and since what you?re seeing on Windows doesn?t match what I?m seeing I think there might be some variation based on OS version. The easiest way out of this thicket is to de-maximize the stage before trying to change its size.

With that said, yes, this Linux bug definitely needs to be fixed. Whatever happens the scene shouldn?t break.

> On Apr 16, 2025, at 3:32?AM, Thiago Milczarek Say?o <thiago.sayao at gmail.com> wrote:
> 
> 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

Option A forces the client to de-maximize the window before changing its size. Option B de-maximizes the window automatically. Option C is the only one that brings new functionality to the table but it would be complicated to implement (assuming it can be implemented).

The documentation states that this is how things work when a stage is in fullscreen mode but from I can tell that?s not how any of the platforms actually behave. Trying to resize a fullscreen window produces a variety of immediate platform-specific effects.

> If I understood correctly, Martin mentioned that both macOS and Windows apply the resize immediately while keeping the window maximized.

You understood correctly but I was wrong. On Windows 11 the size changes (I?m seeing only one resize event) and the window stays in the maximized state. This seems to be confusing the OS and it draws the title bar incorrectly. On macOS the size changes and the window leaves the maximized state but due to a bug in the code we don?t update the maximized property correctly.

Martin

> 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 <mailto: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 <mailto:thiago.sayao at gmail.com>> escreveu:
>>> @Christopher Schnick <mailto: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 <mailto: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 <mailto: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/20250417/8915af40/attachment.htm>

From mstrauss at openjdk.org  Thu Apr 17 20:47:53 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Apr 2025 20:47:53 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
Message-ID: <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>

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

> 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()"

It seems a bit unusual to remove the default style class of a control. If you use a `Hyperlink` control, you also want the result to be hyperlinky and inherit all the hyperlinky styles. This is probably the reason why this control was used here in the first place.

If you don't want your control to be hyperlinky (and also not buttony), the cleaner solution would be to not use `Hyperlink`, but derive a new control from the look-less `ButtonBase` instead, which doesn't come with default styling.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2813986302

From angorya at openjdk.org  Thu Apr 17 21:08:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 21:08:51 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <30v2JmZmU-Qr-KcD51smWwzs4GxKWdl3qjM_oPT5gBE=.8fbce58b-82af-4d26-8a35-13570547b2c8@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
 <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>
 <30v2JmZmU-Qr-KcD51smWwzs4GxKWdl3qjM_oPT5gBE=.8fbce58b-82af-4d26-8a35-13570547b2c8@github.com>
Message-ID: <H4Ufmyox81atoEIIEMiZoDaSw0SRhf5LGtU-IMGYsag=.7cb90db9-7458-4825-8c9e-95f5683a102f@github.com>

On Wed, 16 Apr 2025 23:30:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I do not know if we do, as there is also non-public code that I don't have access to.  I've kept them as-is to make sure the change is focused and doesn't break anything else.
>> 
>> If I had to guess then probably not, if you can ask around and find out I'll be happy to remove them.
>
> I'll double check and will let you know tomorrow.
> 
> A code search shows that these are only used in 5 classes: ButtonBar, ButtonBarSkin, Dialog, DialogPane, Properties, so chances are it's a digital fossil.

I can confirm that we don't use these `//$NON-NLS-*` comments in javaFX.

`<rant>`
These comments were invented as a way to solve the localization problem.  The problem is real, but the "solution" was exactly the opposite.  Instead of marking the strings that don't need to be localized, what should have happened is to mark the string that need to be localized - with the information containing the context!

example:

// verb, as in "execute this test"
String run = "Run";


What I've done with some other projects was 


String run = TXT.get("Class.LocalizedResourceID.verb, as in execute this test", "Run");


`</rant>`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2049645839

From angorya at openjdk.org  Thu Apr 17 21:21:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 21:21:55 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
Message-ID: <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>

On Thu, 17 Apr 2025 20:44:57 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> If you use a `Hyperlink` control, you also want the result to be hyperlinky and inherit all the hyperlinky styles

not necessarily, if you want all the functionality but different visuals.

BTW, the circular button in the DialogPane looks nothing like other modena buttons.  I suspect the code was transplanted from some other project.  May be the DialogPane should have used the TitledPane for the expandable content, to be visually consistent with the rest of javaFX?

In any case, I think it is wrong to retain the hyperlink style in this case.  What I agree with is that it should not use `setAll()` to wipe out the existing styles, because the `createDetailsButton()` is a protected method and the application can override it to set some other base style.

So my suggestion would be:
- remove the `hyperlink` style
- set `details-button` style
- add/remove `less`/`more` styles as proposed in this PR

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2814045926

From mstrauss at openjdk.org  Thu Apr 17 21:27:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Apr 2025 21:27:45 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
Message-ID: <7OSot91FO8tsOiN0wIEHVsLUJPUnIpWk-PF6F4Yw3ig=.dae968ea-7a8d-4419-a63c-4797304421e2@github.com>

On Thu, 17 Apr 2025 21:19:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > If you use a `Hyperlink` control, you also want the result to be hyperlinky and inherit all the hyperlinky styles
> 
> not necessarily, if you want all the functionality but different visuals.

Yes, but the only thing `Hyperlink` adds from a functionality standpoint is the `visited` property, and that's not even used in this case.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2814054437

From angorya at openjdk.org  Thu Apr 17 21:35:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 21:35:49 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <7OSot91FO8tsOiN0wIEHVsLUJPUnIpWk-PF6F4Yw3ig=.dae968ea-7a8d-4419-a63c-4797304421e2@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <7OSot91FO8tsOiN0wIEHVsLUJPUnIpWk-PF6F4Yw3ig=.dae968ea-7a8d-4419-a63c-4797304421e2@github.com>
Message-ID: <p3gPFKFBu5zNZ-nHXAqrbx1W1d1P4lq2ixiCFQUm6Ro=.e4032306-0827-4558-ad1e-c14e20ea1020@github.com>

On Thu, 17 Apr 2025 21:24:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `visited` property,

agree.  2014 was like, ten thousand years ago ;-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2814065143

From angorya at openjdk.org  Thu Apr 17 22:14:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Apr 2025 22:14:58 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
Message-ID: <pHfs3XRz8H5gfLpTHQRpF3aRKwky31o6Cu79Q4_g8Nw=.63a2ff40-13a9-445c-a41f-698fea1e4507@github.com>

On Tue, 15 Apr 2025 10:56:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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

`StageStyle.EXTENDED` also works in a `Dialog`:

![Screenshot 2025-04-17 at 15 02 19](https://github.com/user-attachments/assets/5e34e4e3-01e7-4c67-9413-41efb387fc71)

Marked as reviewed by angorya (Reviewer).

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2777042003
PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2777042625

From almatvee at openjdk.org  Thu Apr 17 23:49:22 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 17 Apr 2025 23:49:22 GMT
Subject: RFR: 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC
 over HTTP/FILE [v2]
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: <Dy5LClDHAamahlQL0m9JILSsfg_vf-C8QQ9qmYYzFqE=.7ddf63e3-faf6-48b3-83e8-5137447f5a4a@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.

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

  8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE [v2]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1775/files
  - new: https://git.openjdk.org/jfx/pull/1775/files/f335dc9e..e24f8ec9

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

  Stats: 46 lines in 2 files changed: 12 ins; 8 del; 26 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 almatvee at openjdk.org  Thu Apr 17 23:49:22 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 17 Apr 2025 23:49:22 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: <AZHPDmehFx3xgeb0C5Fnfl4tKx_sSOrUwN-8pcn2bFw=.fb45d930-26da-4ada-b1b7-e9d01c8a55eb@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.

8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE [v2]
- Fixed latest comments.

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

PR Comment: https://git.openjdk.org/jfx/pull/1775#issuecomment-2814213174

From crschnick at xpipe.io  Fri Apr 18 05:44:45 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 18 Apr 2025 07:44:45 +0200
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <E6B4F323-F26B-479C-A279-0373C9B76125@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>
 <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@mail.gmail.com>
 <E6B4F323-F26B-479C-A279-0373C9B76125@gmail.com>
Message-ID: <3b1378be-7be6-4836-822e-b6c61804fe9a@xpipe.io>

I wasn't really trying it, our application just had functionality to 
resize the window on a certain action. And this functionality then broke 
the window content when triggered while the window was maximized, which 
is a case I didn't consider. I implemented a workaround for this now by 
just setting the maximized property to false prior and only resizing the 
window if really necessary, but I can imagine other applications 
possibly being affected by this.

For reference, here is a video on how the issue looked like initially on 
Linux: https://github.com/xpipe-io/xpipe/issues/485

On 17/04/2025 22:24, Martin Fox wrote:
> Christopher,
>
> Why are you trying to change the size of a maximized stage? I?m not 
> sure what the intended effect is.
>
> Currently this produces all sort of platform-specific behavior and 
> since what you?re seeing on Windows doesn?t match what I?m seeing I 
> think there might be some variation based on OS version. The easiest 
> way out of this thicket is to de-maximize the stage before trying to 
> change its size.
>
> With that said, yes, this Linux bug definitely needs to be fixed. 
> Whatever happens the scene shouldn?t break.
>
>> On Apr 16, 2025, at 3:32?AM, Thiago Milczarek Say?o 
>> <thiago.sayao at gmail.com> wrote:
>>
>> 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
>
> Option A forces the client to de-maximize the window before changing 
> its size. Option B de-maximizes the window automatically. Option C is 
> the only one that brings new functionality to the table but it would 
> be complicated to implement (assuming it can be implemented).
>
> The documentation states that this is how things work when a stage is 
> in fullscreen mode but from I can tell that?s not how any of the 
> platforms actually behave. Trying to resize a fullscreen window 
> produces a variety of immediate platform-specific effects.
>
>> If I understood correctly, Martin mentioned that both macOS and 
>> Windows apply the resize immediately while keeping the window maximized.
>
> You understood correctly but I was wrong. On Windows 11 the size 
> changes (I?m seeing only one resize event) and the window stays in the 
> maximized state. This seems to be confusing the OS and it draws the 
> title bar incorrectly. On macOS the size changes and the window leaves 
> the maximized state but due to a bug in the code we don?t update the 
> maximized property correctly.
>
> Martin
>
>> 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 <mailto: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 MaximizeLinuxBugextends 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 StringcreateCss() {
>>>                          return """ * { -fx-border-color: red;
>>>                 -fx-border-width: 1; } """;
>>>                      }
>>>
>>>                      private RegioncreateContent() {
>>>                          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/20250418/9676b739/attachment-0001.htm>

From jbhaskar at openjdk.org  Fri Apr 18 07:05:16 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 18 Apr 2025 07:05:16 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 and libxslt to 1.1.43
Message-ID: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>

As part of the current WebKit JFX  upgrade, it is required to update libxml and libxslt to compatible versions. Additionally, this release addresses several known issues from the previous version to improve stability and performance.

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

Commit messages:
 - white space fix remainings
 - Revert "remove whitespace error"
 - remove whitespace error
 - remove whitespace error
 - remove whitespace error
 - Executable files are not allowed in github
 - 8352162: Update libxml2 to 2.13.6 and libxslt to 1.1.43

Changes: https://git.openjdk.org/jfx/pull/1785/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352162
  Stats: 180523 lines in 225 files changed: 121965 ins; 23633 del; 34925 mod
  Patch: https://git.openjdk.org/jfx/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1785/head:pull/1785

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

From jhendrikx at openjdk.org  Fri Apr 18 09:24:51 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 18 Apr 2025 09:24:51 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <H4Ufmyox81atoEIIEMiZoDaSw0SRhf5LGtU-IMGYsag=.7cb90db9-7458-4825-8c9e-95f5683a102f@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
 <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>
 <30v2JmZmU-Qr-KcD51smWwzs4GxKWdl3qjM_oPT5gBE=.8fbce58b-82af-4d26-8a35-13570547b2c8@github.com>
 <H4Ufmyox81atoEIIEMiZoDaSw0SRhf5LGtU-IMGYsag=.7cb90db9-7458-4825-8c9e-95f5683a102f@github.com>
Message-ID: <9pVItLkEYHlye-0TA4_7vy4sYXScnmCJe-xPvmnJhxw=.00b0f29e-3b73-4030-b5e9-264cf57f138f@github.com>

On Thu, 17 Apr 2025 21:06:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I'll double check and will let you know tomorrow.
>> 
>> A code search shows that these are only used in 5 classes: ButtonBar, ButtonBarSkin, Dialog, DialogPane, Properties, so chances are it's a digital fossil.
>
> I can confirm that we don't use these `//$NON-NLS-*` comments in javaFX.
> 
> `<rant>`
> These comments were invented as a way to solve the localization problem.  The problem is real, but the "solution" was exactly the opposite.  Instead of marking the strings that don't need to be localized, what should have happened is to mark the string that need to be localized - with the information containing the context!
> 
> example:
> 
> // verb, as in "execute this test"
> String run = "Run";
> 
> 
> What I've done with some other projects was 
> 
> 
> String run = TXT.get("Class.LocalizedResourceID.verb, as in execute this test", "Run");
> 
> 
> `</rant>`

Okay, I can remove them.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2050403015

From jhendrikx at openjdk.org  Fri Apr 18 09:29:49 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 18 Apr 2025 09:29:49 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
Message-ID: <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>

On Thu, 17 Apr 2025 21:19:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > If you use a `Hyperlink` control, you also want the result to be hyperlinky and inherit all the hyperlinky styles
> 
> not necessarily, if you want all the functionality but different visuals.
> 
> BTW, the circular button in the DialogPane looks nothing like other modena buttons. I suspect the code was transplanted from some other project. May be the DialogPane should have used the TitledPane for the expandable content, to be visually consistent with the rest of javaFX?
> 
> In any case, I think it is wrong to retain the hyperlink style in this case. What I agree with is that it should not use `setAll()` to wipe out the existing styles, because the `createDetailsButton()` is a protected method and the application can override it to set some other base style.
> 
> So my suggestion would be:
> 
> * remove the `hyperlink` style
> * set `details-button` style
> * add/remove `less`/`more` styles as proposed in this PR

So... you want me to add more styles so it then ends up looking like a correctly colored hyperlink?

Wouldn't it be easier to do this the other way around, leave the hyperlink style, then apply any specific styling that is needed to make a details-button?

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2815067847

From jhendrikx at openjdk.org  Fri Apr 18 09:42:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 18 Apr 2025 09:42:54 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
 <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
Message-ID: <mdhk-aiiC4uQ9VygoLJUncWdR77b2dQMlalOQbkILRs=.6024a250-b44b-4266-9d95-cb2ce88941e1@github.com>

On Wed, 12 Mar 2025 01:28:49 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Finished the 2nd part of the implementation review. I didn't delve into the logic of the listener management, but it looks sane :)
> 
> I'll review the tests as the final part.

@nlisker did you have time to look at the final part?

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

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2815088005

From mhanl at openjdk.org  Fri Apr 18 11:01:51 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 18 Apr 2025 11:01:51 GMT
Subject: Integrated: 8354794: [TestBug] LocalDateTimeStringConverterTest: Not
 all Tests needs to be parameterized
In-Reply-To: <yQKqEdALoPElZ1XAwHDzPN37Q6EZs9B42SEJizo1wUc=.568db329-68b2-4fd8-96f4-f9f1d76d2a7e@github.com>
References: <yQKqEdALoPElZ1XAwHDzPN37Q6EZs9B42SEJizo1wUc=.568db329-68b2-4fd8-96f4-f9f1d76d2a7e@github.com>
Message-ID: <TlCXP7StC9LpMw_E2XV-pz-CpgsX6U5NeQP8qvSyEQ8=.d9d3ee4a-1102-4373-92af-ce5bfab3b04f@github.com>

On Wed, 16 Apr 2025 18:23:01 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> As discussed in #1778, those test does not need to be parameterized, we therefore can replace `@ParameterizedTest` and `@MethodSource` with `@Test`.

This pull request has now been integrated.

Changeset: a25935d1
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a25935d1b2778223901cec0d07b3f2f4d4be665b
Stats:     7 lines in 1 file changed: 1 ins; 3 del; 3 mod

8354794: [TestBug] LocalDateTimeStringConverterTest: Not all Tests needs to be parameterized

Reviewed-by: angorya

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

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

From zjx001202 at gmail.com  Fri Apr 18 12:29:07 2025
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 18 Apr 2025 20:29:07 +0800
Subject: Proposal: A new common Image API
In-Reply-To: <0caed3d7-3b9a-408c-8752-54a69fd84129@status6.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <0caed3d7-3b9a-408c-8752-54a69fd84129@status6.com>
Message-ID: <CAJL5A3k9ye4=6fgGhRWTLpvTFRT1VZnjjo1+UMdrSdNhPJnoGg@mail.gmail.com>

Hi John,

Thank you very much for your reply. I think you are actually talking about
two problems:

For compact storage, I think the first choice would be something like
PixelBuffer. Pixels can be stored in MemorySegment.
When the pixel format needs to be converted, it is easier to accelerate
using SIMD instructions, which should have better performance.

For general image I/O, I don't think an intermediate format is necessary,
at least not to store the entire image.
I think we can provide an ImageBuilder interface, and the actual
implementation stores pixels in the same way as the Image implementation.
When reading an image, the pixels can be written directly into the
ImageBuilder.
Writing pixels one by one may result in a performance loss, but only one
row or one block of pixels need to be cached for batch writing,
and there is no need to read the entire image in advance.
Finally, the internal structure of ImageBuilder can be reused directly to
create an Image without copying or converting it again.

However, this is just a rough idea, and there are still many problems to be
solved, such as color space,
background loading, progressive loading, animated images, motion photos,
etc.

Glavo

On Thu, Apr 17, 2025 at 3:35?AM John Neffenger <john at status6.com> wrote:

> On 4/16/25 3:04 AM, Glavo wrote:
>
> * 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 was initially frustrated by the split between Java (AWT) and JavaFX in
> their image support and would have welcomed a common library, but I came to
> appreciate the flexibility of having both available in a JavaFX
> application. Below are some thoughts.
>
> The challenge is not just in reading various external image formats. There
> are three parts:
>
>    1. Efficiently loading and converting an image from an external format
>    (GIF, PNG, JPG).
>    2. Efficiently storing images internally with a minimal number of bits
>    per pixel.
>    3. Efficiently converting the internal format to that required by the
>    client library (AWT, JavaFX, Android).
>
> The first item is determined by the external image format standards, but
> the second and third items involve a trade-off. Optimizing for memory usage
> might results in a huge waste of CPU time doing conversions, while
> optimizing for zero conversion time might results in a huge waste of RAM. A
> JavaFX application can pick and choose between this trade-off by using both
> the AWT and JavaFX image libraries.
>
> For example, I had to load and display hundreds of binary images (pure
> black and white) on a constrained device. The AWT can store images in
> memory as one bit per pixel, but JavaFX supports only 32-bit images. So I
> needed to use the AWT image format in memory, but the JavaFX image format
> for display, converting them on-the-fly one-by-one to 32 bits per pixel.
>
> JavaFX provides an AWT-to-JavaFX image conversion utility, called
> SwingFXUtils::toFxImage
> <https://github.com/openjdk/jfx/blob/master/modules/javafx.swing/src/main/java/javafx/embed/swing/SwingFXUtils.java>,
> but I couldn't use it because it was far too slow. It's slow because it's
> generic and has to work for all image types. I came up with 14 different
> ways to convert <https://github.com/jgneff/tofximage> an AWT image to a
> JavaFX image: 9 that work for images with transparency and another 5 that
> work only for images with no alpha. In my case, one such conversion was much
> faster than the others <https://jgneff.github.io/tofximage/2020-06/>.
>
> A common library might end up too generic, too slow, or require too much
> memory to be useful.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250418/0cd2007e/attachment.htm>

From jbhaskar at openjdk.org  Fri Apr 18 13:03:28 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 18 Apr 2025 13:03:28 GMT
Subject: RFR: 8354876: Update SQLite to 3.49.1
Message-ID: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>

As part of the current WebKit JFX upgrade, it is required to update sqlite to compatible versions. Additionally, this release addresses known issues from the previous version to improve stability and performance.

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

Commit messages:
 - whitespace error cleanup
 - update sqllite

Changes: https://git.openjdk.org/jfx/pull/1786/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354876
  Stats: 13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod
  Patch: https://git.openjdk.org/jfx/pull/1786.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1786/head:pull/1786

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

From kcr at openjdk.org  Fri Apr 18 13:36:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Apr 2025 13:36:57 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 and libxslt to 1.1.43
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <n-IkpV5g2WPz9BzkvedJvy8jwTjfaXeq6m2S9gahDBw=.2b703311-5b6a-467e-92a8-bc72ef4a46e1@github.com>

On Fri, 18 Apr 2025 05:41:38 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> As part of the current WebKit JFX  upgrade, it is required to update libxml and libxslt to compatible versions. Additionally, this release addresses several known issues from the previous version to improve stability and performance.

@jaybhaskar You need to change the title back to the original: `Update libxml2 to 2.13.6`. Then use the `/issue add 8352164` command to add the libxslt update bug, [JDK-8352164](https://bugs.openjdk.org/browse/JDK-8352164).

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2815463212

From jbhaskar at openjdk.org  Fri Apr 18 14:36:26 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 18 Apr 2025 14:36:26 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 [v2]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <wnsTDgt1PJqbIJTkQBZsUC1-VeZyaTph9HKaLMBAIQg=.6c5dd818-2f9c-4dc5-a710-fb8b2f891dc9@github.com>

> As part of the current WebKit JFX  upgrade, it is required to update libxml and libxslt to compatible versions. Additionally, this release addresses several known issues from the previous version to improve stability and performance.

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

  remove un-needed files

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/38f16895..fc549b02

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

  Stats: 6001 lines in 9 files changed: 0 ins; 6001 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1785/head:pull/1785

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

From angorya at openjdk.org  Fri Apr 18 14:42:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Apr 2025 14:42:59 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
Message-ID: <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>

On Fri, 18 Apr 2025 09:26:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> So... you want me to add more styles so it then ends up looking like a correctly colored hyperlink?

No.  I would like to retain the existing functionality where the styles alternate between
`[ "details-button", "less" ]` and `[ "details-button", "more" ]`

If you look at the existing code, the setAll() in line 825 gets invoked at the moment the details button is created because the listener gets called in line 829.

So basically, your new code needs one change in (new) line 822:

`styleClasses.setAll("details-button");`

the rest is good.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2815571644

From kcr at openjdk.org  Fri Apr 18 14:42:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Apr 2025 14:42:54 GMT
Subject: RFR: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
References: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
Message-ID: <qq4-rfei77-qhq2eE1GtS1RfdSyOM-t5IoJwaue3moc=.53e71523-3793-407d-b241-caa694911050@github.com>

On Fri, 18 Apr 2025 12:03:22 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> As part of the current WebKit JFX upgrade, it is required to update sqlite to compatible versions. Additionally, this release addresses known issues from the previous version to improve stability and performance.

Reviewers: @tiainen @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1786#issuecomment-2815573378

From angorya at openjdk.org  Fri Apr 18 14:42:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Apr 2025 14:42:59 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <9pVItLkEYHlye-0TA4_7vy4sYXScnmCJe-xPvmnJhxw=.00b0f29e-3b73-4030-b5e9-264cf57f138f@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <SvHP79kGVG2pTcy6mPGqZeWyMdtlcHOPtJFiFLxfCYw=.d58431db-8267-429b-b6a3-67fbea8d4d8d@github.com>
 <mFS-59jpzFJVlc0YsxqdXd0CPsIW__LQX5Zy8P4qJOo=.ec43ecd6-a3a1-4464-9a5e-123b841a538b@github.com>
 <30v2JmZmU-Qr-KcD51smWwzs4GxKWdl3qjM_oPT5gBE=.8fbce58b-82af-4d26-8a35-13570547b2c8@github.com>
 <H4Ufmyox81atoEIIEMiZoDaSw0SRhf5LGtU-IMGYsag=.7cb90db9-7458-4825-8c9e-95f5683a102f@github.com>
 <9pVItLkEYHlye-0TA4_7vy4sYXScnmCJe-xPvmnJhxw=.00b0f29e-3b73-4030-b5e9-264cf57f138f@github.com>
Message-ID: <okVgfGCH5gyR6Mag1ZIdrMFS9CPH0oJTfsz6iTi_m-Q=.e023f547-68f1-4131-bdf4-5c13f15b94cb@github.com>

On Fri, 18 Apr 2025 09:22:27 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I can confirm that we don't use these `//$NON-NLS-*` comments in javaFX.
>> 
>> `<rant>`
>> These comments were invented as a way to solve the localization problem.  The problem is real, but the "solution" was exactly the opposite.  Instead of marking the strings that don't need to be localized, what should have happened is to mark the string that need to be localized - with the information containing the context!
>> 
>> example:
>> 
>> // verb, as in "execute this test"
>> String run = "Run";
>> 
>> 
>> What I've done with some other projects was 
>> 
>> 
>> String run = TXT.get("Class.LocalizedResourceID.verb, as in execute this test", "Run");
>> 
>> 
>> `</rant>`
>
> Okay, I can remove them.

line 822 should be

`styleClasses.setAll("details-button");`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1779#discussion_r2050722617

From kcr at openjdk.org  Fri Apr 18 14:46:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Apr 2025 14:46:57 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 [v2]
In-Reply-To: <wnsTDgt1PJqbIJTkQBZsUC1-VeZyaTph9HKaLMBAIQg=.6c5dd818-2f9c-4dc5-a710-fb8b2f891dc9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <wnsTDgt1PJqbIJTkQBZsUC1-VeZyaTph9HKaLMBAIQg=.6c5dd818-2f9c-4dc5-a710-fb8b2f891dc9@github.com>
Message-ID: <zRGJqOXSQDjxRurJZIBo6MtGnIvqemv4mEm49dW665E=.b4a54933-44d1-4191-a46e-abe3bdda7fc2@github.com>

On Fri, 18 Apr 2025 14:36:26 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> As part of the current WebKit JFX  upgrade, it is required to update libxml and libxslt to compatible versions. Additionally, this release addresses several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove un-needed files

> As part of the current WebKit JFX upgrade, it is required to update libxml and libxslt to compatible versions.

The libxml2 and libxslt libraries are used by WebKit, but are updated independently. So this isn't related to the recent WebKit update. Please update the description to remove this, as it could give the incorrect impression that the current libxml2 and libxslt libraries aren't compatible.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2815579155

From kcr at openjdk.org  Fri Apr 18 14:46:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Apr 2025 14:46:58 GMT
Subject: RFR: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
References: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
Message-ID: <PVfrz-eTE3fsY-L1syktcvbe4cFnEaLHionqZ_tKXP0=.cd9054e0-13cd-41b6-8737-695e9bc6ea80@github.com>

On Fri, 18 Apr 2025 12:03:22 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> As part of the current WebKit JFX upgrade, it is required to update sqlite to compatible versions.

The SQLite library is used by WebKit, but is updated independently. So this isn't related to the recent WebKit update. Please update the description to remove this, as it could give the incorrect impression that the current SQlite isn't compatible.

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

PR Comment: https://git.openjdk.org/jfx/pull/1786#issuecomment-2815579577

From angorya at openjdk.org  Fri Apr 18 23:03:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Apr 2025 23:03:35 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v7]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <36-P07vcPXuZ1OZfXAB__sXHnvvB2K64FO3gSaQvjbA=.a7406b12-2384-469f-99cd-ac049a833474@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 25 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/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
 - ... and 15 more: https://git.openjdk.org/jfx/compare/a25935d1...0adcd2a5

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

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=06
  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 zjx001202 at gmail.com  Sat Apr 19 03:37:57 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 19 Apr 2025 11:37:57 +0800
Subject: Proposal: A new common Image API
In-Reply-To: <em9886d188-f022-4179-8e6a-4333e193eedb@f434645e.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
 <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
 <em9886d188-f022-4179-8e6a-4333e193eedb@f434645e.com>
Message-ID: <CAJL5A3nNDG96Szn9nRqjU+UyNJp72LjTAJLtRBNP5pb8ckASFw@mail.gmail.com>

Hi Jeremy,

The purpose of my email is to:


   1. Find out if people feel the work is worth the effort.
   2. Find out if there is anyone willing to take the lead.
   3. Discuss how this work will begin.

I did have a draft design, but I was not an expert in the field, so I knew
it had a lot of flaws.
I guess if that's what people really want, then people should have their
own ideas about it.
So instead of presenting this flawed idea, I wanted to discuss other things
first.

Once I've determined that the work is worth the effort, but no expert has
the free time to take the lead,
I'll try to implement it myself and then seek guidance.

What is the difference between what you?re describing and the Apache
> Commons Imaging project itself?


Apache Commons Imaging currently depends on AWT BufferedImage. It does not
include the things mentioned in the email.

Glavo

On Fri, Apr 18, 2025 at 4:37?AM Jeremy Wood <mickleness at gmail.com> wrote:

> What is the scope / ideal feature set of this project? (Can you start
> outlining some of the main interfaces you?re envisioning? maybe in a
> google doc?)
>
> What exactly are you looking for in this email thread? Are you looking for
> resources (mostly people?) who can work on this project? Or are you looking
> to see if OpenJDK is willing/able to maintain this API? (or something else?)
>
> What is the difference between what you?re describing and the Apache
> Commons Imaging project itself?
>
> I assume this project is strictly related to reading & writing images. So
> it will NOT support anything analogous to:
> 1. Graphics2D
> 2. AffineTransform
> 3. PerspectiveTransform
> 4. Fonts
> 5. MultiResolutionImage
>
>  - Jeremy
>
> obligatory xkcd reference:
>
> https://www.explainxkcd.com/wiki/index.php/927:_Standards
>
> ------ Original Message ------
> From "Scott Palmer" <swpalmer at gmail.com>
> To "Philip Race" <philip.race at oracle.com>
> Cc "Glavo" <zjx001202 at gmail.com>; "openjfx-dev" <openjfx-dev at openjdk.org>;
> client-libs-dev at openjdk.org
> Date 4/17/2025 12:57:17?PM
> Subject Re: Proposal: A new common Image API
>
> I think a common image I/O library that is not tied to a UI
> framework makes sense and is long overdue.
> Raster images do have a common format that encapsulates everything. We
> essentially have this abstracted in the two UI frameworks already. At some
> level it comes down to PixelFormats and data buffers.  There are not so
> many of them that it is impossible to make a common abstraction for the
> purposes of I/O that can be mapped to what is needed by the UI framework.
> Just as JavaFX already has the SwingFxUtils for converting between AWT and
> JavaFX formats, there can be a utility to convert between the I/O library
> format and each UI framework's format. I would expect in most cases that
> the raw pixel data could be shared without extra copying.
> ImageIO is a good starting point. Remove the actual UI classes from it
> like BufferedImage and keep plain raster representations of the data that
> can be wrapped by the UI classes.  Under the hood the arrays or buffers of
> raster data don't have to change,they are the important parts that the I/O
> library needs to deal with.  Mapping the metadata (width, height, colour
> space, pixel format, etc.) will usually be very cheap. Some cases may need
> to run a conversion, like the example of 1-bpp black/white needing to be
> remapped to RGB, but that that can happen in the utility layer that moves
> the image from the Image I/O domain to the UI framework domain on a
> case-by-case basis. Worst case is that the UI framework throws an
> UnsupportImageFormat exception when it doesn't have code to deal with
> raster data in a particular format.
>
> I'm sure it is all much harder than I suspect, but I don't think it should
> be. :-)
>
> Scott
>
>
> On Thu, Apr 17, 2025 at 12:10?AM Philip Race <philip.race at oracle.com>
> wrote:
>
>> First, note than John Neffenger replied to this but only on openjfx-dev
>> and the first thing I saw was the reply and couldn't see the original.
>> After some consternation I tracked down this cross-post.
>>
>> Here's a link to the reply
>> https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html
>>
>> A fundamental problem is that all the users need to be able to produce
>> and consume the data.
>> So there either needs to be a module dependency (not viable) or an
>> agreed format (are we
>> really going to define an image format which encapsulates everything,
>> including the multi-frame
>> GIF support) and then everyone needs a reader and don't forget writers
>> and they need to be able to do .. so much ..
>>
>> I just don't see a viable path here.
>> And several (8 ?) years ago, I pondered some way to separate image
>> handling from the
>> desktop module to see if a server app could use it without pulling in
>> AWT but the intra-package
>> dependencies made it impossible without changes I didn't even figure out
>> if they were possible.
>>
>> -phil.
>>
>> On 4/16/25 3:04 AM, Glavo wrote:
>> > 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/20250419/080a6bc8/attachment.htm>

From kevin.rushforth at oracle.com  Sat Apr 19 16:11:04 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 19 Apr 2025 09:11:04 -0700
Subject: Proposal: A new common Image API
In-Reply-To: <CAJL5A3nNDG96Szn9nRqjU+UyNJp72LjTAJLtRBNP5pb8ckASFw@mail.gmail.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
 <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
 <em9886d188-f022-4179-8e6a-4333e193eedb@f434645e.com>
 <CAJL5A3nNDG96Szn9nRqjU+UyNJp72LjTAJLtRBNP5pb8ckASFw@mail.gmail.com>
Message-ID: <ee898b74-818d-45db-8238-09517666a509@oracle.com>

I agree with Phil on this. I don't see enough value in creating yet 
another image library in the JDK to justify the effort and the weight of 
the API and implementation. We would need to design, specify, implement, 
and support a new imaging API all while maintaining the existing JavaFX 
and Java2D imaging libraries. We wouldn't deprecate the existing imaging 
libraries in favor of the new one, at least not any time in the next 
several years (if ever), so we would either end up with three 
implementations (instead of two) or additional effort to redo the 
implementation BufferedImage, Raster, Image, etc, on top of the new 
library. Similarly for JavaFX's (smaller) implementation. And then 
there's Image IO, which would also need to be redone.

So I am not at all optimistic about this, and I doubt this is something 
we should pursue.

--Kevin


On 4/18/2025 8:37 PM, Glavo wrote:
> Hi?Jeremy,
>
> The purpose of my email is to:
>
>  1. Find out if people feel the work is worth the effort.
>  2. Find out if there is anyone willing to take the lead.
>  3. Discuss how this work will begin.
>
> I did have a draft design, but I was not an expert in the field, so I 
> knew it had a lot of flaws.
> I guess if that's what people really want, then people should have 
> their own ideas about it.
> So instead of presenting this flawed idea, I wanted to discuss other 
> things first.
>
> Once I've determined that the work is worth the effort, but no expert 
> has the free time to take the lead,
> I'll try to implement it myself and then seek guidance.
>
>     What is the difference between what you?re describing and the
>     Apache Commons Imaging project itself?
>
>
> Apache Commons Imaging currently depends on AWT BufferedImage. It does 
> not include the things mentioned in the email.
>
> Glavo
>
> On Fri, Apr 18, 2025 at 4:37?AM Jeremy Wood <mickleness at gmail.com> wrote:
>
>     What is the scope / ideal feature set of this project? (Can you
>     start outlining some of the main interfaces you?re envisioning?
>     maybe in a google doc?)
>
>     What exactly are you looking for in this email thread? Are you
>     looking for resources (mostly people?) who can work on this
>     project? Or are you looking to see if OpenJDK is willing/able to
>     maintain this API? (or something else?)
>
>     What is the difference between what you?re describing and the
>     Apache Commons Imaging project itself?
>
>     I assume this project is strictly related to reading & writing
>     images. So it will NOT support anything analogous to:
>     1. Graphics2D
>     2. AffineTransform
>     3. PerspectiveTransform
>     4. Fonts
>     5. MultiResolutionImage
>
>     ?- Jeremy
>
>     obligatory xkcd reference:
>
>     https://www.explainxkcd.com/wiki/index.php/927:_Standards
>
>     ------ Original Message ------
>     From "Scott Palmer" <swpalmer at gmail.com>
>     To "Philip Race" <philip.race at oracle.com>
>     Cc "Glavo" <zjx001202 at gmail.com>; "openjfx-dev"
>     <openjfx-dev at openjdk.org>; client-libs-dev at openjdk.org
>     Date 4/17/2025 12:57:17?PM
>     Subject Re: Proposal: A new common Image API
>
>>     I think a common image I/O library that is not tied to a UI
>>     framework?makes sense and is long overdue.
>>     Raster images do have a common format that encapsulates
>>     everything. We essentially have this abstracted in the two UI
>>     frameworks already. At some level it comes down to PixelFormats
>>     and data buffers. There are not so many of them that it is
>>     impossible to make a common abstraction for the purposes of I/O
>>     that can be mapped to what is needed by the UI framework.
>>     Just as JavaFX already has the SwingFxUtils for converting
>>     between AWT and JavaFX formats, there can be a utility to convert
>>     between the I/O library format and each UI framework's format. I
>>     would expect in most cases that the raw pixel data could be
>>     shared without extra copying.
>>     ImageIO is a good starting point. Remove the actual UI classes
>>     from it like BufferedImage and keep plain raster representations
>>     of the data that can be wrapped by the UI classes.? Under the
>>     hood the arrays or buffers of raster data don't have to
>>     change,they are the important parts that the I/O library?needs to
>>     deal with.? Mapping the metadata (width, height, colour space,
>>     pixel format, etc.) will usually be very cheap. Some cases may
>>     need to run a conversion, like the example of 1-bpp black/white
>>     needing to be remapped to RGB, but that that can happen in the
>>     utility layer that moves the image from the Image I/O domain to
>>     the UI framework domain on a case-by-case basis. Worst case is
>>     that the UI framework throws an UnsupportImageFormat exception
>>     when it doesn't have code to deal with raster data in a
>>     particular format.
>>
>>     I'm sure it is all much harder than I suspect, but I don't think
>>     it should be. :-)
>>
>>     Scott
>>
>>
>>     On Thu, Apr 17, 2025 at 12:10?AM Philip Race
>>     <philip.race at oracle.com> wrote:
>>
>>         First, note than John Neffenger replied to this but only on
>>         openjfx-dev
>>         and the first thing I saw was the reply and couldn't see the
>>         original.
>>         After some consternation I tracked down this cross-post.
>>
>>         Here's a link to the reply
>>         https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html
>>
>>         A fundamental problem is that all the users need to be able
>>         to produce
>>         and consume the data.
>>         So there either needs to be a module dependency (not viable)
>>         or an
>>         agreed format (are we
>>         really going to define an image format which encapsulates
>>         everything,
>>         including the multi-frame
>>         GIF support) and then everyone needs a reader and don't
>>         forget writers
>>         and they need to be able to do .. so much ..
>>
>>         I just don't see a viable path here.
>>         And several (8 ?) years ago, I pondered some way to separate
>>         image
>>         handling from the
>>         desktop module to see if a server app could use it without
>>         pulling in
>>         AWT but the intra-package
>>         dependencies made it impossible without changes I didn't even
>>         figure out
>>         if they were possible.
>>
>>         -phil.
>>
>>         On 4/16/25 3:04 AM, Glavo wrote:
>>         > 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/20250419/8063a057/attachment-0001.htm>

From kcr at openjdk.org  Sat Apr 19 16:18:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 19 Apr 2025 16:18:49 GMT
Subject: RFR: 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC
 over HTTP/FILE [v2]
In-Reply-To: <Dy5LClDHAamahlQL0m9JILSsfg_vf-C8QQ9qmYYzFqE=.7ddf63e3-faf6-48b3-83e8-5137447f5a4a@github.com>
References: <R-ffhVyTAJn_nKduqOc1JtVWwxRUN-JgxveUIJNeLag=.8e4b0f80-8698-47f5-aa87-9eae30e2f736@github.com>
 <Dy5LClDHAamahlQL0m9JILSsfg_vf-C8QQ9qmYYzFqE=.7ddf63e3-faf6-48b3-83e8-5137447f5a4a@github.com>
Message-ID: <5FsUbuXDusVmLoPWXuLW-n_CdFUHig_-zGToz90KqEM=.4fcb04d7-a944-4a1c-b261-71ae9ec841b8@github.com>

On Thu, 17 Apr 2025 23:49:22 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.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE [v2]

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1775#pullrequestreview-2780020189

From zjx001202 at gmail.com  Sat Apr 19 17:33:17 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 20 Apr 2025 01:33:17 +0800
Subject: Proposal: A new common Image API
In-Reply-To: <ee898b74-818d-45db-8238-09517666a509@oracle.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
 <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
 <em9886d188-f022-4179-8e6a-4333e193eedb@f434645e.com>
 <CAJL5A3nNDG96Szn9nRqjU+UyNJp72LjTAJLtRBNP5pb8ckASFw@mail.gmail.com>
 <ee898b74-818d-45db-8238-09517666a509@oracle.com>
Message-ID: <CAJL5A3k9GiRvgvsiEtZa2LR03pDOKgB1fy+3MSn8et35nx_ghg@mail.gmail.com>

Hi Kevin,

Going from two implementations to three is really frustrating. But what?s
even more frustrating is
that the Java ecosystem now doesn?t have just two implementations?it has
five, six, or even more.
In addition to AWT and JavaFX, there are Android, SWT, Qt Jambi, and Skija,
along with countless other image libraries.

The problem isn?t that there are multiple implementations, but that none of
them are common enough,
so developers keep reinventing the wheel. Here?s a recent example:
jxlatte[1]. It?s a pure Java JPEG XL decoder.
To avoid depending on java.desktop, its developers once again created new
abstractions for colors and images.

The current situation is chaotic for the entire ecosystem and also sets a
high barrier for creating new libraries.
Developing a small library for image processing should be simple,
but now developers have to think carefully before starting?and might even
end up reinventing the wheel themselves.
This also creates a poor experience for users.

I?m not suggesting we deprecate all existing implementations, but I do
think a new common library is important.
This library should provide a unified facade for existing implementations
(SLF4J is a good example)
and prevent developers from having to reinvent the wheel repeatedly.

Glavo

[1]: https://github.com/Traneptora/jxlatte

On Sun, Apr 20, 2025 at 12:11?AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I agree with Phil on this. I don't see enough value in creating yet
> another image library in the JDK to justify the effort and the weight of
> the API and implementation. We would need to design, specify, implement,
> and support a new imaging API all while maintaining the existing JavaFX and
> Java2D imaging libraries. We wouldn't deprecate the existing imaging
> libraries in favor of the new one, at least not any time in the next
> several years (if ever), so we would either end up with three
> implementations (instead of two) or additional effort to redo the
> implementation BufferedImage, Raster, Image, etc, on top of the new
> library. Similarly for JavaFX's (smaller) implementation. And then there's
> Image IO, which would also need to be redone.
>
> So I am not at all optimistic about this, and I doubt this is something we
> should pursue.
>
> --Kevin
>
>
> On 4/18/2025 8:37 PM, Glavo wrote:
>
> Hi Jeremy,
>
> The purpose of my email is to:
>
>
>    1. Find out if people feel the work is worth the effort.
>    2. Find out if there is anyone willing to take the lead.
>    3. Discuss how this work will begin.
>
> I did have a draft design, but I was not an expert in the field, so I knew
> it had a lot of flaws.
> I guess if that's what people really want, then people should have their
> own ideas about it.
> So instead of presenting this flawed idea, I wanted to discuss other
> things first.
>
> Once I've determined that the work is worth the effort, but no expert has
> the free time to take the lead,
> I'll try to implement it myself and then seek guidance.
>
> What is the difference between what you?re describing and the Apache
>> Commons Imaging project itself?
>
>
> Apache Commons Imaging currently depends on AWT BufferedImage. It does not
> include the things mentioned in the email.
>
> Glavo
>
> On Fri, Apr 18, 2025 at 4:37?AM Jeremy Wood <mickleness at gmail.com> wrote:
>
>> What is the scope / ideal feature set of this project? (Can you start
>> outlining some of the main interfaces you?re envisioning? maybe in a
>> google doc?)
>>
>> What exactly are you looking for in this email thread? Are you looking
>> for resources (mostly people?) who can work on this project? Or are you
>> looking to see if OpenJDK is willing/able to maintain this API? (or
>> something else?)
>>
>> What is the difference between what you?re describing and the Apache
>> Commons Imaging project itself?
>>
>> I assume this project is strictly related to reading & writing images. So
>> it will NOT support anything analogous to:
>> 1. Graphics2D
>> 2. AffineTransform
>> 3. PerspectiveTransform
>> 4. Fonts
>> 5. MultiResolutionImage
>>
>>  - Jeremy
>>
>> obligatory xkcd reference:
>>
>> https://www.explainxkcd.com/wiki/index.php/927:_Standards
>>
>> ------ Original Message ------
>> From "Scott Palmer" <swpalmer at gmail.com>
>> To "Philip Race" <philip.race at oracle.com>
>> Cc "Glavo" <zjx001202 at gmail.com>; "openjfx-dev" <openjfx-dev at openjdk.org>;
>> client-libs-dev at openjdk.org
>> Date 4/17/2025 12:57:17?PM
>> Subject Re: Proposal: A new common Image API
>>
>> I think a common image I/O library that is not tied to a UI
>> framework makes sense and is long overdue.
>> Raster images do have a common format that encapsulates everything. We
>> essentially have this abstracted in the two UI frameworks already. At some
>> level it comes down to PixelFormats and data buffers.  There are not so
>> many of them that it is impossible to make a common abstraction for the
>> purposes of I/O that can be mapped to what is needed by the UI framework.
>> Just as JavaFX already has the SwingFxUtils for converting between AWT
>> and JavaFX formats, there can be a utility to convert between the I/O
>> library format and each UI framework's format. I would expect in most cases
>> that the raw pixel data could be shared without extra copying.
>> ImageIO is a good starting point. Remove the actual UI classes from it
>> like BufferedImage and keep plain raster representations of the data that
>> can be wrapped by the UI classes.  Under the hood the arrays or buffers of
>> raster data don't have to change,they are the important parts that the I/O
>> library needs to deal with.  Mapping the metadata (width, height, colour
>> space, pixel format, etc.) will usually be very cheap. Some cases may need
>> to run a conversion, like the example of 1-bpp black/white needing to be
>> remapped to RGB, but that that can happen in the utility layer that moves
>> the image from the Image I/O domain to the UI framework domain on a
>> case-by-case basis. Worst case is that the UI framework throws an
>> UnsupportImageFormat exception when it doesn't have code to deal with
>> raster data in a particular format.
>>
>> I'm sure it is all much harder than I suspect, but I don't think it
>> should be. :-)
>>
>> Scott
>>
>>
>> On Thu, Apr 17, 2025 at 12:10?AM Philip Race <philip.race at oracle.com>
>> wrote:
>>
>>> First, note than John Neffenger replied to this but only on openjfx-dev
>>> and the first thing I saw was the reply and couldn't see the original.
>>> After some consternation I tracked down this cross-post.
>>>
>>> Here's a link to the reply
>>> https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html
>>>
>>> A fundamental problem is that all the users need to be able to produce
>>> and consume the data.
>>> So there either needs to be a module dependency (not viable) or an
>>> agreed format (are we
>>> really going to define an image format which encapsulates everything,
>>> including the multi-frame
>>> GIF support) and then everyone needs a reader and don't forget writers
>>> and they need to be able to do .. so much ..
>>>
>>> I just don't see a viable path here.
>>> And several (8 ?) years ago, I pondered some way to separate image
>>> handling from the
>>> desktop module to see if a server app could use it without pulling in
>>> AWT but the intra-package
>>> dependencies made it impossible without changes I didn't even figure out
>>> if they were possible.
>>>
>>> -phil.
>>>
>>> On 4/16/25 3:04 AM, Glavo wrote:
>>> > 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/20250420/b82034ed/attachment-0001.htm>

From zjx001202 at gmail.com  Sat Apr 19 18:09:19 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sun, 20 Apr 2025 02:09:19 +0800
Subject: Proposal: A new common Image API
In-Reply-To: <0CDBC7B1-8257-4918-986D-CB53556E1BE5@mac.com>
References: <CAJL5A3m=06Z-mL+EKiCGv2wK6JgEn=31OpSgv1WuRtwY3fKtFA@mail.gmail.com>
 <484ae025-47dc-462e-b6bd-e4fce3252005@oracle.com>
 <CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com>
 <em9886d188-f022-4179-8e6a-4333e193eedb@f434645e.com>
 <CAJL5A3nNDG96Szn9nRqjU+UyNJp72LjTAJLtRBNP5pb8ckASFw@mail.gmail.com>
 <ee898b74-818d-45db-8238-09517666a509@oracle.com>
 <CAJL5A3k9GiRvgvsiEtZa2LR03pDOKgB1fy+3MSn8et35nx_ghg@mail.gmail.com>
 <0CDBC7B1-8257-4918-986D-CB53556E1BE5@mac.com>
Message-ID: <CAJL5A3kyzopW+_QW6_Ta7FfEcg_DwRjZTJANfaov0ksGKhK8PQ@mail.gmail.com>

Hi Andrew,

To be honest, I think splitting up java.desktop might be impossible.
The APIs in this module have dependencies on each other, and I can't figure
out how to split it up without breaking compatibility.

For example, javax.imageio.ImageIO has several APIs that return a
java.awt.image.BufferedImage,
and BufferedImage::createGraphics() returns a java.awt.Graphics2D.
Considering that a package cannot be split into multiple JPMS modules, this
means that java.awt, java.awt.image,
and javax.imageio are tightly linked. Such coupling is everywhere in
java.desktop. I think splitting it is just a delusion.
I don't understand why so many people expect it. I think creating a new
module containing a new API is the pragmatic choice.

Glavo

On Sun, Apr 20, 2025 at 1:56?AM Andrew Thompson <lordpixel at mac.com> wrote:

> Reading this thread as an outsider, the things that keep coming up over
> and over again is that java.desktop needs to be modularized.
> This sounds like painstaking slow work which would doubtless requires many
> long interactions to get approvals and not offer much glory.
>
> But is that where the value really is?
>
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250420/4807f7a7/attachment.htm>

From mfox at openjdk.org  Sun Apr 20 15:14:46 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sun, 20 Apr 2025 15:14:46 GMT
Subject: Withdrawn: 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: <08G1_yFCjt6iFjDCihX-XFAalDpmXzvW-91D41-GJ2Y=.3972bb56-3799-44bd-b6f9-9cd78b67a36e@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.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Apr 21 05:36:47 2025
From: duke at openjdk.org (duke)
Date: Mon, 21 Apr 2025 05:36:47 GMT
Subject: RFR: 8296554: MouseLocationOnScreenTest sometime fails when system
 is busy [v5]
In-Reply-To: <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
References: <fLPcJgZVEjvtRQucj9DLS7THGUsGbhVhFavQqN--zrM=.3b6da38d-ae9d-4384-b6ac-150e73ad1e3a@github.com>
 <QxCcotoz8soCn1xUTiC-pocKJP8_bZMEJ9eZWcAWqDM=.fb0d04b2-43fe-48af-982b-6f2465ca4fd8@github.com>
Message-ID: <3jyAE1uK3IbVi3XbLhCJlvFy7KwLyT1Y8o25pxvGbLk=.9bad6999-20e9-4967-b490-eddccdf7985b@github.com>

On Thu, 17 Apr 2025 05:57: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.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

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

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

PR Comment: https://git.openjdk.org/jfx/pull/1772#issuecomment-2817673792

From jbhaskar at openjdk.org  Mon Apr 21 06:05:36 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 21 Apr 2025 06:05:36 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 [v3]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <uk4yU0ndeJbkAGaXBF0W4kPEq0YwSeb4agPsQZWy-eM=.9aa1e265-7fd9-433c-87c8-f18978911e65@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  remove some non required files and update to 2.13.8

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/fc549b02..19ede147

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

  Stats: 25488 lines in 27 files changed: 3894 ins; 21584 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1785/head:pull/1785

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

From duke at openjdk.org  Mon Apr 21 06:39:49 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 21 Apr 2025 06:39:49 GMT
Subject: Integrated: 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: <dqOsUMRmMxGIi3K1cD_-VdzVlqBpF9XJa-NwbIuYlUM=.e67bb115-0ae4-4c34-87b7-38765b1f2a52@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.

This pull request has now been integrated.

Changeset: 703a9a90
Author:    Gopal Pattnaik <gopal.pattnaik at oracle.com>
Committer: Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/703a9a9049c75c6f0fe04082b4ad97e1f97eb1f5
Stats:     19 lines in 1 file changed: 16 ins; 3 del; 0 mod

8296554: MouseLocationOnScreenTest sometime fails when system is busy

Reviewed-by: kcr, angorya

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

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

From arapte at openjdk.org  Mon Apr 21 07:47:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 21 Apr 2025 07:47:46 GMT
Subject: RFR: 8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC
 over HTTP/FILE [v2]
In-Reply-To: <Dy5LClDHAamahlQL0m9JILSsfg_vf-C8QQ9qmYYzFqE=.7ddf63e3-faf6-48b3-83e8-5137447f5a4a@github.com>
References: <R-ffhVyTAJn_nKduqOc1JtVWwxRUN-JgxveUIJNeLag=.8e4b0f80-8698-47f5-aa87-9eae30e2f736@github.com>
 <Dy5LClDHAamahlQL0m9JILSsfg_vf-C8QQ9qmYYzFqE=.7ddf63e3-faf6-48b3-83e8-5137447f5a4a@github.com>
Message-ID: <LHeR2A-1gkb_v3aWDfsbWvaR90pEABRgvL57DALlXWQ=.8b0e1fbe-e97a-4cfc-9ff5-e413ea9575aa@github.com>

On Thu, 17 Apr 2025 23:49:22 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.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE [v2]

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1775#pullrequestreview-2780754642

From angorya at openjdk.org  Mon Apr 21 15:18:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 21 Apr 2025 15:18:02 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@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 27 commits:

 - rm junit4
 - 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/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
 - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc

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

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=07
  Stats: 1382 lines in 10 files changed: 1323 ins; 29 del; 30 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 jbhaskar at openjdk.org  Mon Apr 21 15:31:04 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 21 Apr 2025 15:31:04 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 [v4]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <7YFVIVPg_hNBng1EUJ6fX126mSV-PnTUkPFb3iNsgcI=.5138ff6e-4992-4557-b61f-722980f0a600@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  remove libxml2.rc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/19ede147..1ea01cc1

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

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

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

From jbhaskar at openjdk.org  Mon Apr 21 15:44:02 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 21 Apr 2025 15:44:02 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.6 [v5]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <zeY1f8VuFiy-qB1WbYwTIRBzHJlXa7pY8evyj26Jn40=.5adfaeb6-7d38-434a-b704-681a95c9e65a@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  clean files , they do not require

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/1ea01cc1..0dbc2e96

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

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

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

From kcr at openjdk.org  Mon Apr 21 16:53:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Apr 2025 16:53:52 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v5]
In-Reply-To: <zeY1f8VuFiy-qB1WbYwTIRBzHJlXa7pY8evyj26Jn40=.5adfaeb6-7d38-434a-b704-681a95c9e65a@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <zeY1f8VuFiy-qB1WbYwTIRBzHJlXa7pY8evyj26Jn40=.5adfaeb6-7d38-434a-b704-681a95c9e65a@github.com>
Message-ID: <VkVHehcrYWr8pCiN-1k0aR1ok7ZY6f9UNmv0d-IrtPQ=.5ffb597c-6446-49eb-9f6d-25771880f7e4@github.com>

On Mon, 21 Apr 2025 15:44:02 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean files , they do not require

I'll check the list of added / removed files in addition to checking the (small set of) updates from 2.13.6 --> 2.13.8.

Also, in case you missed seeing it, you have a white-space error.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2819005016

From jbhaskar at openjdk.org  Mon Apr 21 17:28:12 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 21 Apr 2025 17:28:12 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  remove unused files

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/0dbc2e96..5c4b05d0

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

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

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

From kcr at openjdk.org  Mon Apr 21 18:18:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Apr 2025 18:18:47 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
Message-ID: <67NvuPU9VAfZLg6xAIwJ1z4fWEAUBZhKcZHj7dMh260=.0ec58cb1-158a-4e8d-a3cf-eceeadd6809b@github.com>

On Mon, 21 Apr 2025 17:28:12 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused files

The list of removed files looks good.

I see several files were added in this update that aren't part of the 2.12.x --> 2.13.x update (e.g., `xmlschemas.c`). Can you check whether these are actually needed? I suspect that most aren't.

I will do the same cross check for libxslt next.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2819184508

From martinfox656 at gmail.com  Mon Apr 21 20:04:07 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 21 Apr 2025 13:04:07 -0700
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <3b1378be-7be6-4836-822e-b6c61804fe9a@xpipe.io>
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>
 <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@mail.gmail.com>
 <E6B4F323-F26B-479C-A279-0373C9B76125@gmail.com>
 <3b1378be-7be6-4836-822e-b6c61804fe9a@xpipe.io>
Message-ID: <F2760FD8-7B98-4599-9313-8D3841BD4A00@gmail.com>

Christopher ? Thanks for the details.

Thiago ? I?m still of the opinion that we shouldn?t try to specify what happens when a client tries to resize a maximized window. I don?t like leaving these things unspecified but I?m not sure there?s a compelling use case that would justify the effort involved in nailing this down. Simpler to just document that the window should be de-maximized first.

I?m also seeing some bugs on macOS related to maximizing and de-maximizing the window and it looks like we don?t have good system tests for some of this (or they?re disabled). Personally I would rather focus on fixing those issues.

Martin

> On Apr 17, 2025, at 10:44?PM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> I wasn't really trying it, our application just had functionality to resize the window on a certain action. And this functionality then broke the window content when triggered while the window was maximized, which is a case I didn't consider. I implemented a workaround for this now by just setting the maximized property to false prior and only resizing the window if really necessary, but I can imagine other applications possibly being affected by this.
> 
> For reference, here is a video on how the issue looked like initially on Linux: https://github.com/xpipe-io/xpipe/issues/485
> 
> On 17/04/2025 22:24, Martin Fox wrote:
>> Christopher,
>> 
>> Why are you trying to change the size of a maximized stage? I?m not sure what the intended effect is.
>> 
>> Currently this produces all sort of platform-specific behavior and since what you?re seeing on Windows doesn?t match what I?m seeing I think there might be some variation based on OS version. The easiest way out of this thicket is to de-maximize the stage before trying to change its size.
>> 
>> With that said, yes, this Linux bug definitely needs to be fixed. Whatever happens the scene shouldn?t break.
>> 
>>> On Apr 16, 2025, at 3:32?AM, Thiago Milczarek Say?o <thiago.sayao at gmail.com> <mailto:thiago.sayao at gmail.com> wrote:
>>> 
>>> 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
>> 
>> Option A forces the client to de-maximize the window before changing its size. Option B de-maximizes the window automatically. Option C is the only one that brings new functionality to the table but it would be complicated to implement (assuming it can be implemented).
>> 
>> The documentation states that this is how things work when a stage is in fullscreen mode but from I can tell that?s not how any of the platforms actually behave. Trying to resize a fullscreen window produces a variety of immediate platform-specific effects.
>> 
>>> If I understood correctly, Martin mentioned that both macOS and Windows apply the resize immediately while keeping the window maximized.
>> 
>> You understood correctly but I was wrong. On Windows 11 the size changes (I?m seeing only one resize event) and the window stays in the maximized state. This seems to be confusing the OS and it draws the title bar incorrectly. On macOS the size changes and the window leaves the maximized state but due to a bug in the code we don?t update the maximized property correctly.
>> 
>> Martin
>> 
>>> 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 <mailto: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 <mailto:thiago.sayao at gmail.com>> escreveu:
>>>>> @Christopher Schnick <mailto: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 <mailto: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 <mailto: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/20250421/f31e39cb/attachment-0001.htm>

From almatvee at openjdk.org  Mon Apr 21 20:28:47 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 21 Apr 2025 20:28:47 GMT
Subject: Integrated: 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: <JhBF59LgnfudtBpywa6yJfBceMKHP_uFvDadWsaIs74=.5604946b-af09-45bf-9e3d-89ddf3cddd6e@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.

This pull request has now been integrated.

Changeset: d1fcca71
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d1fcca716a09788e376ac24c23be3e6861e492be
Stats:     187 lines in 2 files changed: 138 ins; 17 del; 32 mod

8329227: Seek might hang with fMP4 H.265/HEVC or H.265/HEVC over HTTP/FILE

Reviewed-by: arapte, kcr

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

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

From kcr at openjdk.org  Mon Apr 21 20:36:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Apr 2025 20:36:59 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <67NvuPU9VAfZLg6xAIwJ1z4fWEAUBZhKcZHj7dMh260=.0ec58cb1-158a-4e8d-a3cf-eceeadd6809b@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
 <67NvuPU9VAfZLg6xAIwJ1z4fWEAUBZhKcZHj7dMh260=.0ec58cb1-158a-4e8d-a3cf-eceeadd6809b@github.com>
Message-ID: <MUArBI9wxltWdD_NxQtVBQVg1TvUScbNq2QDb_Mdmvg=.f145b9da-68af-425f-a035-f817b9b76696@github.com>

On Mon, 21 Apr 2025 18:16:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I see several files were added in this update that aren't part of the 2.12.x --> 2.13.x update (e.g., `xmlschemas.c`). Can you check whether these are actually needed? I suspect that most aren't.

Here is the complete list for you to check:


libxml/src/CMakeLists.txt
libxml/src/SAX.c
libxml/src/c14n.c
libxml/src/catalog.c
libxml/src/chvalid.def
libxml/src/config.h.cmake.in
libxml/src/debugXML.c
libxml/src/include/Makefile.am
libxml/src/include/libxml/meson.build
libxml/src/include/meson.build
libxml/src/include/private/Makefile.am
libxml/src/include/private/regexp.h
libxml/src/include/private/xinclude.h
libxml/src/include/private/xzlib.h
libxml/src/relaxng.c
libxml/src/rngparser.c
libxml/src/runsuite.c
libxml/src/runtest.c
libxml/src/runxmlconf.c
libxml/src/xinclude.c
libxml/src/xlink.c
libxml/src/xml2-config.in
libxml/src/xmlcatalog.c
libxml/src/xmllint.c
libxml/src/xmlmodule.c
libxml/src/xmlregexp.c
libxml/src/xmlschemas.c
libxml/src/xmlschemastypes.c
libxml/src/xpointer.c
libxml/src/xzlib.c

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2819450820

From kcr at openjdk.org  Mon Apr 21 20:36:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Apr 2025 20:36:59 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
Message-ID: <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>

On Mon, 21 Apr 2025 17:28:12 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused files

I left some inline feedback on the libxml2 update.

I provided one more example of a libxml2 file that was not new in the 2.13.x release, but which was added as part of this PR (there are 30 such files. I will list them in a separate comment).

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/config.h line 29:

> 27: 
> 28: /* getentropy */
> 29: #define HAVE_GETENTROPY 0

The pattern in `config.h` is to comment out the define for an unused feature, not to define it to 0. This is important because most of the conditional defines are checked using `#ifdef` or `#if defined`, and those macros don't care what the value is.

This needs to be fixed. If this feature is now needed, the define it as follows:


/* Define to 1 if you have the 'getentropy' function. */
#define HAVE_GETENTROPY 1


else comment it out as follows:


/* Define to 1 if you have the 'getentropy' function. */
/* #undef HAVE_GETENTROPY */

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/config.h line 67:

> 65: 
> 66: /* Define to 1 if you have the <poll.h> header file. */
> 67: /* #undef HAVE_POLL_H */

Is this no longer needed?

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/config.h line 97:

> 95: 
> 96: /* Define to 1 if you have the <sys/random.h> header file. */
> 97: #define HAVE_SYS_RANDOM_H 0

This also needs to be fixed (either define it to 1 or else comment it out).

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/include/libxml/xmlversion.h line 322:

> 320:  * the string suffix used by dynamic modules (usually shared libraries)
> 321:  */
> 322: #define LIBXML_MODULE_EXTENSION ".so

This looks wrong. It would almost certainly fail to compile if the code path were active. You might want to fix it, although it is unused.

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/mac/config.h line 29:

> 27: 
> 28: /* getentropy */
> 29: #define HAVE_GETENTROPY 1

I think the comment should be:


/* Define to 1 if you have the 'getentropy' function. */


Can you check this?

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/mac/include/xmlversion.h line 1:

> 1: /*

This file is not used and should be deleted. It looks like a spurious copy of `mac/include/libxml/xmlversion.h`.

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/CMakeLists.txt line 1:

> 1: cmake_minimum_required(VERSION 3.18)

I don't think we use this file in our build. We should remove it if not.

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/SAX.c line 2:

> 1: /*
> 2:  * SAX.c : Old SAX v1 handlers to build a tree.

Here is an example of what I mentioned earlier: This is a file that we didn't used to take from the upstream. I don't think we use it or need it.

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/dict.c line 933:

> 931: #else
> 932:   // This block will compile on macOS (and any non-Linux system) if HAVE_GETENTROPY is defined
> 933:   #if defined(HAVE_GETENTROPY) && !defined(__linux__)

Can you check whether this is needed if `HAVE_GETENTROPY` is left undefined? I suspect it will no longer be necessary, and it would be better not to have local mods to upstream files.

If a modification _is_ needed, then we will need a clear comment with the changes, noting that this is a JavaFX-specific addition.

modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/tree.c line 5862:

> 5860:  *
> 5861:  * Merge the second text node into the first. The second node is
> 5862:  * unlinked and freed.

It looks like you missed applying one of the changes from 2.13.7. Replace the above two lines with:


 * Merge the second text node into the first. If @first is NULL,
 * @second is returned. Otherwise, the second node is unlinked and
 * freed.

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

PR Review: https://git.openjdk.org/jfx/pull/1785#pullrequestreview-2781990520
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052845497
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052864462
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052861880
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052866676
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052869329
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052877696
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052878445
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052926586
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052935612
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2052940458

From thiago.sayao at gmail.com  Mon Apr 21 20:37:47 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 21 Apr 2025 17:37:47 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <F2760FD8-7B98-4599-9313-8D3841BD4A00@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>
 <CAAP_wu=sZsokR6cNz=65Fsb-D7oLBcozcNbcR=XPbOujANicsw@mail.gmail.com>
 <E6B4F323-F26B-479C-A279-0373C9B76125@gmail.com>
 <3b1378be-7be6-4836-822e-b6c61804fe9a@xpipe.io>
 <F2760FD8-7B98-4599-9313-8D3841BD4A00@gmail.com>
Message-ID: <CAAP_wunMjUo8KzaFZhn6p7w56+O3y2uGwBShdAJnmaiieJ91YA@mail.gmail.com>

Martin,

I agree ? this behavior is likely to be platform-specific, and it could be
difficult to guarantee consistent results if we try to enforce a specific
outcome. It seems more practical to document that variations should be
expected.

I'll be filing a PR soon with fixes for Glass on Linux, along with
additional tests related to window sizing, positioning and window state
management.

-- Thiago.

Em seg., 21 de abr. de 2025 ?s 17:04, Martin Fox <martinfox656 at gmail.com>
escreveu:

> Christopher ? Thanks for the details.
>
> Thiago ? I?m still of the opinion that we shouldn?t try to specify what
> happens when a client tries to resize a maximized window. I don?t like
> leaving these things unspecified but I?m not sure there?s a compelling use
> case that would justify the effort involved in nailing this down. Simpler
> to just document that the window should be de-maximized first.
>
> I?m also seeing some bugs on macOS related to maximizing and de-maximizing
> the window and it looks like we don?t have good system tests for some of
> this (or they?re disabled). Personally I would rather focus on fixing those
> issues.
>
> Martin
>
> On Apr 17, 2025, at 10:44?PM, Christopher Schnick <crschnick at xpipe.io>
> wrote:
>
> I wasn't really trying it, our application just had functionality to
> resize the window on a certain action. And this functionality then broke
> the window content when triggered while the window was maximized, which is
> a case I didn't consider. I implemented a workaround for this now by just
> setting the maximized property to false prior and only resizing the window
> if really necessary, but I can imagine other applications possibly being
> affected by this.
>
> For reference, here is a video on how the issue looked like initially on
> Linux: https://github.com/xpipe-io/xpipe/issues/485
> On 17/04/2025 22:24, Martin Fox wrote:
>
> Christopher,
>
> Why are you trying to change the size of a maximized stage? I?m not sure
> what the intended effect is.
>
> Currently this produces all sort of platform-specific behavior and since
> what you?re seeing on Windows doesn?t match what I?m seeing I think there
> might be some variation based on OS version. The easiest way out of this
> thicket is to de-maximize the stage before trying to change its size.
>
> With that said, yes, this Linux bug definitely needs to be fixed. Whatever
> happens the scene shouldn?t break.
>
> On Apr 16, 2025, at 3:32?AM, Thiago Milczarek Say?o
> <thiago.sayao at gmail.com> <thiago.sayao at gmail.com> wrote:
>
> 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
>
>
> Option A forces the client to de-maximize the window before changing its
> size. Option B de-maximizes the window automatically. Option C is the only
> one that brings new functionality to the table but it would be complicated
> to implement (assuming it can be implemented).
>
> The documentation states that this is how things work when a stage is in
> fullscreen mode but from I can tell that?s not how any of the platforms
> actually behave. Trying to resize a fullscreen window produces a variety of
> immediate platform-specific effects.
>
> If I understood correctly, Martin mentioned that both macOS and Windows
> apply the resize immediately while keeping the window maximized.
>
>
> You understood correctly but I was wrong. On Windows 11 the size changes
> (I?m seeing only one resize event) and the window stays in the maximized
> state. This seems to be confusing the OS and it draws the title bar
> incorrectly. On macOS the size changes and the window leaves the maximized
> state but due to a bug in the code we don?t update the maximized property
> correctly.
>
> Martin
>
> 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/20250421/a28cddd7/attachment-0001.htm>

From kcr at openjdk.org  Mon Apr 21 22:00:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Apr 2025 22:00:52 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
Message-ID: <O_JgszaIoyad-MwKT5vos5MfDzfW_3stV5Tfgv-UOcM=.a94a0685-4095-4eb1-b9cd-5396da35d7a8@github.com>

On Mon, 21 Apr 2025 17:28:12 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused files

I reviewed the `libxslt` update. There are only three issues I saw:

1. The addition of the `libexslt` dir should be reverted
2. The `src/CMakeLists.txt` is likely unneeded and should be removed
4. There is an unexpected diff in one file: `congure.ac`

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/CMakeLists.txt line 1:

> 1: cmake_minimum_required(VERSION 3.18)

I don't think we use this file in our build. We should remove it if not.

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/configure.ac line 6:

> 4: m4_define([MAJOR_VERSION], [1])
> 5: m4_define([MINOR_VERSION], [1])
> 6: m4_define([MICRO_VERSION], [44])

This should be `43` not `44`.

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/configure.ac line 24:

> 22: LIBEXSLT_MAJOR_VERSION=0
> 23: LIBEXSLT_MINOR_VERSION=8
> 24: LIBEXSLT_MICRO_VERSION=25

This should be `24` (not `25`).

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libexslt/common.c line 1:

> 1: #define IN_LIBEXSLT

We don't include `libexslt` with jfxwebkit nor do we want to. Please revert the addition of the `libexslt/` directory tree.

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

PR Review: https://git.openjdk.org/jfx/pull/1785#pullrequestreview-2782277174
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053015887
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053016916
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053017222
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053020232

From kcr at openjdk.org  Tue Apr 22 00:11:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 00:11:49 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
Message-ID: <Q_zSX8ZGJJ9IRf-yB-CthGs0O-OrZ-iYZ1KIDxF2ZhU=.69b3f970-8aeb-4d19-a3e2-e3422d60001b@github.com>

On Mon, 21 Apr 2025 17:28:12 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused files

> > I see several files were added in this update that aren't part of the 2.12.x --> 2.13.x update (e.g., `xmlschemas.c`). Can you check whether these are actually needed? I suspect that most aren't.
> 
> Here is the complete list for you to check:
> 
> ```
> ...
> libxml/src/include/private/Makefile.am
> libxml/src/include/private/regexp.h
> libxml/src/include/private/xinclude.h
> libxml/src/include/private/xzlib.h
> ```

Turns out that least one of the .h files in `libxml/src/include/private/` -- `regexp.h` -- is needed, so at least that one (and maybe the others) should not be removed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2819746296

From duke at openjdk.org  Tue Apr 22 07:00:27 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Tue, 22 Apr 2025 07:00:27 GMT
Subject: RFR: 8260020: WebView does not render contents of locally stored
 MarkDown (*.md) files.
Message-ID: <61xe7GY1wwduIUW9ilgSwa9QtF6OfT825eYHYLPeSo4=.a4b432f7-97c5-4a52-ad61-72fe7770fbdc@github.com>

Local markdown file mime type support was missing in open source [JDK-8260020],

Hence, we added a mime type for local Markdown files display.

expected bahaviour: This should display the markdown file content as text in the webview.
Verification:
The test passes with the rendering of local Markdown file.

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

Commit messages:
 - JDK-8260020 Local Markdown files not shown in Webview

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

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

From jbhaskar at openjdk.org  Tue Apr 22 08:50:39 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 08:50:39 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v7]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <95A35vpNYbn1cNazZ6-fgaE8aOkpj-n-0bmMchXrBNg=.67363449-3cad-4e3e-84cb-9183949cddd2@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  remove non required files as by review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/5c4b05d0..95275e7a

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

  Stats: 99839 lines in 61 files changed: 1 ins; 99836 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1785/head:pull/1785

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

From aghaisas at openjdk.org  Tue Apr 22 10:02:55 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 22 Apr 2025 10:02:55 GMT
Subject: RFR: 8260020: WebView does not render contents of locally stored
 MarkDown (*.md) files
In-Reply-To: <61xe7GY1wwduIUW9ilgSwa9QtF6OfT825eYHYLPeSo4=.a4b432f7-97c5-4a52-ad61-72fe7770fbdc@github.com>
References: <61xe7GY1wwduIUW9ilgSwa9QtF6OfT825eYHYLPeSo4=.a4b432f7-97c5-4a52-ad61-72fe7770fbdc@github.com>
Message-ID: <aqe4Htq__wfbjFvuIys4HhQsnu01cw3HTN0VV3bhNTg=.8b6e63fe-4c94-41ec-9d9b-c86262f5f0c5@github.com>

On Tue, 22 Apr 2025 06:54:31 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> Local markdown file mime type support is missing in the current JavaFX implementation. Hence, I have added a mime type for local Markdown files.
> 
> Verification:
> The test program attached to the JBS passes with this change.

I will let others to comment on the fix.
Is it possible to add an automated test?

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

PR Comment: https://git.openjdk.org/jfx/pull/1788#issuecomment-2820814247

From jbhaskar at openjdk.org  Tue Apr 22 10:19:28 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 10:19:28 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v8]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <W2STiX6Hdluay7aJFXbBM2fGuWcTA5rPqdRSgHNjCcw=.957e969c-cc28-4c81-98b9-de8d9d55e5f6@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  fix linux build no need extra code

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/95275e7a..801ba5d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=06-07

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

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

From jbhaskar at openjdk.org  Tue Apr 22 10:32:41 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 10:32:41 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v9]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  add quotes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/801ba5d0..52ce3cfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=07-08

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

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

From jbhaskar at openjdk.org  Tue Apr 22 10:32:44 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 10:32:44 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
 <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
Message-ID: <lrOPqd04OkMKUSMIq-YgPxVU7-DG-LB6wQz4okN2DQ4=.f37bfbdd-59fb-4178-8d8b-d552b6a59a2b@github.com>

On Mon, 21 Apr 2025 18:59:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused files
>
> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/include/libxml/xmlversion.h line 322:
> 
>> 320:  * the string suffix used by dynamic modules (usually shared libraries)
>> 321:  */
>> 322: #define LIBXML_MODULE_EXTENSION ".so
> 
> This looks wrong. It would almost certainly fail to compile if the code path were active. You might want to fix it, although it is unused.

ok , i miss "

> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/CMakeLists.txt line 1:
> 
>> 1: cmake_minimum_required(VERSION 3.18)
> 
> I don't think we use this file in our build. We should remove it if not.

This file is not required , deleted

> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/dict.c line 933:
> 
>> 931: #else
>> 932:   // This block will compile on macOS (and any non-Linux system) if HAVE_GETENTROPY is defined
>> 933:   #if defined(HAVE_GETENTROPY) && !defined(__linux__)
> 
> Can you check whether this is needed if `HAVE_GETENTROPY` is left undefined? I suspect it will no longer be necessary, and it would be better not to have local mods to upstream files.
> 
> If a modification _is_ needed, then we will need a clear comment with the changes, noting that this is a JavaFX-specific addition.

removed custom change

> modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/CMakeLists.txt line 1:
> 
>> 1: cmake_minimum_required(VERSION 3.18)
> 
> I don't think we use this file in our build. We should remove it if not.

this [CMakeLists.txt] not required , i have removed

> modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/configure.ac line 24:
> 
>> 22: LIBEXSLT_MAJOR_VERSION=0
>> 23: LIBEXSLT_MINOR_VERSION=8
>> 24: LIBEXSLT_MICRO_VERSION=25
> 
> This should be `24` (not `25`).

this file is not required, removed now

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053826221
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053827228
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053827841
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053829026
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053829815

From jbhaskar at openjdk.org  Tue Apr 22 10:37:53 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 10:37:53 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
 <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
Message-ID: <TlaOp_D8D-pXiA5-nUiiXEAksWZioNrWzWhs2vW9j8E=.767b2587-362a-43d1-a899-b28f49a80b13@github.com>

On Mon, 21 Apr 2025 19:10:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused files
>
> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/mac/include/xmlversion.h line 1:
> 
>> 1: /*
> 
> This file is not used and should be deleted. It looks like a spurious copy of `mac/include/libxml/xmlversion.h`.

we need to keep [xmlversion.h], when we update we usually compare the macro

> modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/configure.ac line 6:
> 
>> 4: m4_define([MAJOR_VERSION], [1])
>> 5: m4_define([MINOR_VERSION], [1])
>> 6: m4_define([MICRO_VERSION], [44])
> 
> This should be `43` not `44`.

[onfigure.ac] removed now not needed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053836403
PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053839747

From jbhaskar at openjdk.org  Tue Apr 22 11:07:02 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 22 Apr 2025 11:07:02 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v6]
In-Reply-To: <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <ha3VS9DCmaK-zYLTSltDKW3H6dQ8evcyhGSJ1H4LEsk=.fe7857ea-3332-44b0-abd7-b2e81776cf78@github.com>
 <YUbT8DkAwYmN9vCtrssaWRW8S6TZIUeUcFuo_891bsc=.c283148b-be3a-4e74-a637-57a0f075f719@github.com>
Message-ID: <RwWp4PeJPlNW7_8aUrVs78-tUL3Fh5CR5hG7bLZL3CQ=.0abedb85-61a2-43f6-97bf-c45362723902@github.com>

On Mon, 21 Apr 2025 18:57:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused files
>
> modules/javafx.web/src/main/native/Source/ThirdParty/libxml/linux/config.h line 67:
> 
>> 65: 
>> 66: /* Define to 1 if you have the <poll.h> header file. */
>> 67: /* #undef HAVE_POLL_H */
> 
> Is this no longer needed?

this is autogenerated , not my change, it looks valid

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1785#discussion_r2053881215

From tsayao at openjdk.org  Tue Apr 22 12:06:05 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 22 Apr 2025 12:06:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window
 sizing, positioning, and state management issues
Message-ID: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>

This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.


Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.

List of changes:
1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
9. It no longer keeps track of geometry internally, as GTK already manages this - except in special cases, such as when the window has not yet been realized. Previously, it used BoundsType to distinguish between "Window Bounds" and "Content Bounds." Now, it consistently uses "Content Bounds" and converts them to "Window Bounds" by adding extents (decoration sizes) when necessary;
10. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 

A simple manual test is also provided but I would prefer to move it's functionality to monkey tester:
`java @build/run.args tests/manual/stage/TestStage.java `


List of fixed issues:

1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
2. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
3. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
11. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
12. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)

The Xorg-related bugs were not issues within JavaFX itself, so they were addressed through workarounds - such as delaying the initial state and re-checking the geometry when the window is first mapped.

**IMPORTANT**: While this is open for review, please allow me some time to further polish and test it before final approval. Feedback is welcome?especially regarding any need to disable the new tests on specific platforms, as some of them might fail.

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

Commit messages:
 - [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354943
  Stats: 3139 lines in 23 files changed: 2101 ins; 606 del; 432 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From kcr at openjdk.org  Tue Apr 22 16:40:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 16:40:56 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v9]
In-Reply-To: <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
Message-ID: <uR2PrNSw3eWOhSRCQkzfsUeA13V8o8f-SL48tN4HTsU=.e8cc7bdd-5469-4be1-99c3-9710e16b026c@github.com>

On Tue, 22 Apr 2025 10:32:41 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add quotes

With the recent changes, this PR now looks good to me. I still need to do a sanity test. I'll approve after the pending update to the two `/src/main/legal/` files.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2821887652

From kcr at openjdk.org  Tue Apr 22 17:24:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 17:24:39 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <hd_IcdVgc5J9rhYmkf8Ey5Qen5IUNHMI80lxW0R9PtQ=.ffa9b704-851e-4b06-975d-09c69e8322a5@github.com>

On Tue, 22 Apr 2025 12:01:56 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Reviewers: @lukostyra @kevinrushforth

@beldenfox If you have time, your review would be appreciated as well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2821993275

From kcr at openjdk.org  Tue Apr 22 18:22:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 18:22:03 GMT
Subject: RFR: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
References: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
Message-ID: <Ust1AfHHCoR-i8f5s5DainkDnNJcKf5FawKwcsAV47Y=.60744fe8-6175-4cfa-990b-d7ffeec0984f@github.com>

On Fri, 18 Apr 2025 12:03:22 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

Code changes are good. I ran a sanity test and it passed.

@tiainen or @johanvos This is now ready for you to review.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1786#pullrequestreview-2784949727
PR Comment: https://git.openjdk.org/jfx/pull/1786#issuecomment-2822122266

From kcr at openjdk.org  Tue Apr 22 18:22:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 18:22:57 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v9]
In-Reply-To: <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
Message-ID: <1MW6DPYKl6w_8A5QPNVenoVG2IsZbI8VNb3Ml79NQIs=.1f41632d-7a3b-44f3-b3d4-7a9cdf7ca0f5@github.com>

On Tue, 22 Apr 2025 10:32:41 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add quotes

Sanity test passed on all platforms.

@tiainen or @johanvos This is now ready for you to review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1785#issuecomment-2822123976

From kcr at openjdk.org  Tue Apr 22 22:06:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 22:06:53 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
Message-ID: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>

On Mon, 21 Apr 2025 15:18:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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 27 commits:
> 
>  - rm junit4
>  - 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/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
>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc

First batch of comments. This looks like a good start for RichTextArea and CodeArea. I presume you'll handle the rest of the API with other bugs / PRs?

Some of my comments are about expanding the test coverage to handle more cases, and that could be done when you add functional tests.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/CodeAreaTest.java line 77:

> 75: 
> 76:         control = new CodeArea(null);
> 77:         control.setModel(new CodeTextModel() {

Suggestion: Check that the model you set can be read back.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 103:

> 101: 
> 102:         control = new RichTextArea(null);
> 103:         control.setModel(new CustomStyledTextModel());

Suggestion: save `new CustomStyledTextModel()` in a local var and then `assertSame(model, control.getModel());`

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 254:

> 252:     public void appendText() {
> 253:         TextPos p = control.appendText("a");
> 254:         assertEquals(TextPos.ofLeading(0, 1), p);

Suggestion: also check that the character was actually appended, by reading the text back. This suggestion applies to all of the append methods (e.g., when setting a style, check that the style was actually applied).

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 307:

> 305:         control.copy();
> 306:         String s = Clipboard.getSystemClipboard().getString();
> 307:         assertEquals("ax", s);

Suggestion: expand this to check various selection segments and boundary conditions (e.g., test copying when the selection has a single character at the beginning, missing, and end) as well as no selection (clipboard string should be empty).

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 393:

> 391: 
> 392:     @Test
> 393:     public void getParagraphCount() {

Maybe also assert that the paragraph count is initially null?

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 410:

> 408:         control.setModel(null);
> 409:         // on second through, maybe this should return null
> 410:         assertEquals(TextPos.ZERO, control.getParagraphEnd(0));

Are you keeping a list of such API questions?

In this case, I would think that asking for a paragraph that is out of range would throw IOOBE. What does control.getParagraph(N) do when N is out of range? This method should behave similarly.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 444:

> 442: 
> 443: //    @Test
> 444: //    public void insertLineBreak() {

Why is this commented out? A comment explaining why would be good. Or if there is a functional bug that prevents it, uncomment it and skip it with `@Disabled("JDK-8888888")`.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 451:

> 449: 
> 450:     @Test
> 451:     public void isRedoable() {

Do you also have functional tests for undo/redo?

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 466:

> 464: 
> 465:     @Test
> 466:     public void modelChangeClearsSelection() {

Since the actual data is sorted in the model, it might also be good to test that a model change clears all of the text that you have previously appended (in another test method).

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 550:

> 548: 
> 549:     @Test
> 550:     public void redo() {

A test of the undo / redo stack would be helpful (this tests a single undo/redo value, so is a good first step, but doesn't test its "stack" nature).

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/support/RTUtil.java line 41:

> 39:  * Utilities for RichTextArea-based tests.
> 40:  */
> 41: public class RTUtil {

Suggestion: add a private constructor

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/support/TestStyledInput.java line 47:

> 45:         ArrayList<StyledSegment> ss = new ArrayList<>();
> 46:         for (int i = 0; i < lines.length; i++) {
> 47:             if(i > 0) {

Minor: space after `if`

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 40:

> 38: 
> 39: /**
> 40:  * There should be a common place for module-agnostic test utilities.

javafx.base might eventually be a good place for this sort of utility.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 42:

> 40:  * There should be a common place for module-agnostic test utilities.
> 41:  */
> 42: public class TUtil {

Since this is intended to be a static utility class, maybe add a private constructor to underscore this?

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 49:

> 47:         Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> {
> 48:             if (throwable instanceof RuntimeException) {
> 49:                 throw (RuntimeException)throwable;

Why is RuntimeException treated differently than checked Exception and Error?

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

PR Review: https://git.openjdk.org/jfx/pull/1677#pullrequestreview-2785310885
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054949072
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054884101
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054899845
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054922565
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054924225
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054924993
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054929603
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054931387
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054933189
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054943566
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054871418
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054872504
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054862174
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054870939
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054835553

From angorya at openjdk.org  Tue Apr 22 22:39:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Apr 2025 22:39:50 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <-EyIyUoCKB9NbEDfQOMisV8LmGTCoDceej0l2NM5khs=.8a3cb83a-1d0a-42fc-95cd-ea244c30f43b@github.com>

On Tue, 22 Apr 2025 20:36:55 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 49:
> 
>> 47:         Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> {
>> 48:             if (throwable instanceof RuntimeException) {
>> 49:                 throw (RuntimeException)throwable;
> 
> Why is RuntimeException treated differently than checked Exception and Error?

hmmm...  This pattern was copied from some other test.  We have 32 more instances of this pattern elsewhere.

I suspect it is not avoid declaring a checked exception.
What would you suggest?  Forward the `throwable` to `Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable);` unconditionally?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054983255

From angorya at openjdk.org  Tue Apr 22 22:42:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Apr 2025 22:42:49 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>

On Tue, 22 Apr 2025 20:57:46 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 40:
> 
>> 38: 
>> 39: /**
>> 40:  * There should be a common place for module-agnostic test utilities.
> 
> javafx.base might eventually be a good place for this sort of utility.

It might, or perhaps it could be packaged into a jar so we can run single source files + library via JEP 458 `--class-path 'libs/*'` argument?

see "Using pre-compiled classes" section in
https://openjdk.org/jeps/458

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054985673

From angorya at openjdk.org  Tue Apr 22 22:51:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Apr 2025 22:51:48 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <QjyDNN7FcPmtfActfcLQWaUt0Cg14ykh1OTaBBy5VLY=.f3bf29f9-62e8-4c63-aa0e-09a04c0888b2@github.com>

On Tue, 22 Apr 2025 21:39:27 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 393:
> 
>> 391: 
>> 392:     @Test
>> 393:     public void getParagraphCount() {
> 
> Maybe also assert that the paragraph count is initially null?

1 instead of null, there is always at least one paragraph in this model.

> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 410:
> 
>> 408:         control.setModel(null);
>> 409:         // on second through, maybe this should return null
>> 410:         assertEquals(TextPos.ZERO, control.getParagraphEnd(0));
> 
> Are you keeping a list of such API questions?
> 
> In this case, I would think that asking for a paragraph that is out of range would throw IOOBE. What does control.getParagraph(N) do when N is out of range? This method should behave similarly.

good point, let me think about it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054990839
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054991912

From angorya at openjdk.org  Tue Apr 22 22:57:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Apr 2025 22:57:47 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <RrsQpxIff2pt1c_UkSMJpyQ-mSfqnB9KUx2otJwyLAM=.f8c819b9-ba9f-40d2-a2b9-d3849e58805c@github.com>

On Tue, 22 Apr 2025 21:46:02 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 451:
> 
>> 449: 
>> 450:     @Test
>> 451:     public void isRedoable() {
> 
> Do you also have functional tests for undo/redo?

yes, `undo()` and `redo()`

I tried to exercise every public method to some extent.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2054996369

From angorya at openjdk.org  Tue Apr 22 23:02:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Apr 2025 23:02:50 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
Message-ID: <NtFZl3lpjzxFCLoR9bWi9MU3RVIH32HZcA0rOdkS8K4=.8ee16b8b-ad46-4cde-a9ce-fb470e21c866@github.com>

On Mon, 21 Apr 2025 15:18:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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 27 commits:
> 
>  - rm junit4
>  - 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/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
>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc

Thank you, Kevin, good suggestions.

> I presume you'll handle the rest of the API with other bugs / PRs?

Correct - the idea is to follow up with headful behavioral test(s).

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

PR Comment: https://git.openjdk.org/jfx/pull/1677#issuecomment-2822651012

From kcr at openjdk.org  Tue Apr 22 23:14:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 23:14:46 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <jmPhRtd_1PjZsVCz8ZNUXMAQOJB8nkISAtqUbkK8hJo=.e9c600d9-0da0-462c-8093-979f0823bf3f@github.com>

On Tue, 22 Apr 2025 21:47:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Since the actual data is sorted

Typo, I meant "stored"

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2055007843

From kcr at openjdk.org  Tue Apr 22 23:14:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Apr 2025 23:14:47 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>
Message-ID: <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>

On Tue, 22 Apr 2025 22:40:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 40:
>> 
>>> 38: 
>>> 39: /**
>>> 40:  * There should be a common place for module-agnostic test utilities.
>> 
>> javafx.base might eventually be a good place for this sort of utility.
>
> It might, or perhaps it could be packaged into a jar so we can run single source files + library via JEP 458 `--class-path 'libs/*'` argument?
> 
> see "Using pre-compiled classes" section in
> https://openjdk.org/jeps/458

Unit tests already need to load the JavaFX modules, so I don't see how packaging it in a jar would help. All it would do it add one more thing to put on the path.

>> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/util/TUtil.java line 49:
>> 
>>> 47:         Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> {
>>> 48:             if (throwable instanceof RuntimeException) {
>>> 49:                 throw (RuntimeException)throwable;
>> 
>> Why is RuntimeException treated differently than checked Exception and Error?
>
> hmmm...  This pattern was copied from some other test.  We have 32 more instances of this pattern elsewhere.
> 
> I suspect it is not avoid declaring a checked exception.
> What would you suggest?  Forward the `throwable` to `Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable);` unconditionally?

That's interesting that other tests do this. When re-throwing an exception you often need to special case checked exceptions (to wrap them so that the caller doesn't need to explicitly declare it), but the UncaughtExceptionHandler can handle both, so I don't know why it was done that way.

You might try just unconditionally forwarding all throwables, but not sure.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2055006813
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2055005696

From tsayao at openjdk.org  Wed Apr 23 00:43:23 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 23 Apr 2025 00:43:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v2]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <4ZsJyT7qihFsX4tU0ICAsCFy_jM1SqyLRTYqt3fXnf4=.166650ed-8c5d-4041-8d29-9a3a6faf7a2e@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Increase sleep on SizingTest.testFullscreenUnresizable

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/0502b66a..14c89a2f

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

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

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

From tsayao at openjdk.org  Wed Apr 23 01:14:30 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 23 Apr 2025 01:14:30 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v3]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <JzPdNyq8DqtO-DD1d8hEfKlwDA3jR25NgjwBPU4Ze3M=.bed31bba-9434-47ba-9cc8-052eaf93c00d@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Adjust some comments
  - Fix fullscreen unresizable

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/14c89a2f..4593dd6e

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

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

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

From lkostyra at openjdk.org  Wed Apr 23 09:00:56 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 23 Apr 2025 09:00:56 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: <MfNaogFRA48fMDByMTzdz7AcBz7_iOF5fIwGH4NTTDw=.c8ace834-7119-4744-8bc5-e275719c7bdc@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"

Marked as reviewed by lkostyra (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1776#pullrequestreview-2786498590

From tsayao at openjdk.org  Wed Apr 23 09:36:54 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 23 Apr 2025 09:36:54 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v4]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <nr8-iFX33ay3TRw0Zk2tBahY4OeaweX3i8FOMYy-ghA=.16d8ae99-439e-4ce5-b174-0a78ea77377d@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Add check if the window is still alive

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/4593dd6e..14cb8321

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

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

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

From tsayao at openjdk.org  Wed Apr 23 09:46:06 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 23 Apr 2025 09:46:06 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Reenable RestoreSceneSizeTest (JDK-8353556)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/14cb8321..02b6ab30

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

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

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

From sykora at openjdk.org  Wed Apr 23 11:00:48 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 23 Apr 2025 11:00:48 GMT
Subject: RFR: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
References: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
Message-ID: <gJ_81Y0nvpiWJBgEYJsaXVotXaousodHJOYf_dRNdDA=.fc6b8055-a6f0-4088-9d30-b8eacc33eeaf@github.com>

On Fri, 18 Apr 2025 12:03:22 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

The builds ran successfully with these changes.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1786#pullrequestreview-2786882484

From sykora at openjdk.org  Wed Apr 23 11:00:50 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 23 Apr 2025 11:00:50 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v9]
In-Reply-To: <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <e_R_H7a4GPzb_keOHPBP6KeCyjoI8cs7YV_Z6bnY48I=.eea55bc5-3ed5-4735-843c-95caba5cbe6c@github.com>
Message-ID: <obgmqVEw48c4_ZVAtVQhpQiaNy81EXEYp5rpLjbzR68=.4ae639d4-5346-408a-a324-39f62cc8b9d8@github.com>

On Tue, 22 Apr 2025 10:32:41 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add quotes

The builds ran successfully with these changes.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1785#pullrequestreview-2786883388

From jbhaskar at openjdk.org  Wed Apr 23 11:25:10 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 11:25:10 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v10]
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <UGaBiZ2xwBgPTthAp6io1Yw_Lp2znUO6vMBSy1qAnV4=.cbc47cd6-55b1-467e-aade-aac49e6b0b6c@github.com>

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

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

  Adding license attribute for thirdparty libs

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1785/files
  - new: https://git.openjdk.org/jfx/pull/1785/files/52ce3cfb..0f84dcc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1785&range=08-09

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

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

From jbhaskar at openjdk.org  Wed Apr 23 11:28:53 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 11:28:53 GMT
Subject: Integrated: 8354876: Update SQLite to 3.49.1
In-Reply-To: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
References: <Vg8aYcQKWEkcOVWTYlF_4nfaTY3-1OQ-pzVn2hvaLwU=.221b7d75-daa4-46bb-94a5-2f78f54ded60@github.com>
Message-ID: <X6wCA5Hbo9fg3Av8dzT7NI0H-AaRUEh2FMu4Mx8UOCY=.7ba968bc-dc39-4b4c-a3f5-626b6df45149@github.com>

On Fri, 18 Apr 2025 12:03:22 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

This pull request has now been integrated.

Changeset: 46b36fe4
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/46b36fe432aab81468df44344ab5e36aa31c5f47
Stats:     13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod

8354876: Update SQLite to 3.49.1

Reviewed-by: kcr, sykora

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

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

From kcr at openjdk.org  Wed Apr 23 11:45:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 11:45:56 GMT
Subject: RFR: 8352162: Update libxml2 to 2.13.8 [v10]
In-Reply-To: <UGaBiZ2xwBgPTthAp6io1Yw_Lp2znUO6vMBSy1qAnV4=.cbc47cd6-55b1-467e-aade-aac49e6b0b6c@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
 <UGaBiZ2xwBgPTthAp6io1Yw_Lp2znUO6vMBSy1qAnV4=.cbc47cd6-55b1-467e-aade-aac49e6b0b6c@github.com>
Message-ID: <cHMf4T5VH80itfn6Lvcp3jj-10IzpYvrj1qKdG2CDI4=.35c41457-1c69-4f7a-8b37-5dde86994306@github.com>

On Wed, 23 Apr 2025 11:25:10 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> The upgrade is required to address several known issues from the previous version to improve stability and performance.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding license attribute for thirdparty libs

LGTM

The only change since last approval is the updated third-party README content in `/src/main/legal`, so a single re-review is sufficient.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1785#pullrequestreview-2786995996

From jbhaskar at openjdk.org  Wed Apr 23 11:50:50 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 11:50:50 GMT
Subject: Integrated: 8352162: Update libxml2 to 2.13.8
In-Reply-To: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
References: <NLIUHUkxZ2vFhtPV-10fm5h19yR8_ghYVMiPpMVinUA=.4f938c96-e2c5-464a-8517-7c600569bbd9@github.com>
Message-ID: <OG-qfWLsoMnkWqtMmdjujmL5Ei0ia2ZMmdHC1uXRrkw=.577c72d2-9716-4f29-bfda-7cad88434ac9@github.com>

On Fri, 18 Apr 2025 05:41:38 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> The upgrade is required to address several known issues from the previous version to improve stability and performance.

This pull request has now been integrated.

Changeset: 4df23263
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4df2326391b3528c48a4594ec9f3bb6fdde9a437
Stats:     102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod

8352162: Update libxml2 to 2.13.8
8352164: Update libxslt to 1.1.43

Reviewed-by: kcr, sykora

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

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

From kcr at openjdk.org  Wed Apr 23 12:02:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 12:02:26 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: <KxRQGGar4l_FilVKPc4a3-Cp1XJBF5gfzmPoHSiiZEM=.8d0ea86e-2f78-414a-9403-42c7505e81e9@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.

@johanvos Can you add maintainer approval for this bug?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/20#issuecomment-2824046046

From kcr at openjdk.org  Wed Apr 23 12:02:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 12:02:32 GMT
Subject: [jfx24u] RFR: 8354318: freetype.c: compilation error:
 'incompatible pointer type' with gcc 14
In-Reply-To: <UKkQHzzQIC7hiFccO7aGUzTEr02KVLN3jBJ4cp431KQ=.1910887b-9b4d-4518-a34b-a63333772a5d@github.com>
References: <UKkQHzzQIC7hiFccO7aGUzTEr02KVLN3jBJ4cp431KQ=.1910887b-9b4d-4518-a34b-a63333772a5d@github.com>
Message-ID: <AWp6uI4p131V0zCr2esWqvMuP_yrBOCODbhGwrkDZCI=.b4dad3b3-495d-4a8a-86a7-7fd03e0665a3@github.com>

On Mon, 14 Apr 2025 17:40:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of "incompatible pointer type" fix to jfx24u

@johanvos Can you add maintainer approval for this bug?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/21#issuecomment-2824046179

From jdv at openjdk.org  Wed Apr 23 12:19:34 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Apr 2025 12:19:34 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
Message-ID: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>

When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml

By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This changes is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.

Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.

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

Commit messages:
 - PointLightIlluminationTest update
 - 8318985: [macos] Incorrect 3D lighting on macOS 14 and later

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

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

From arapte at openjdk.org  Wed Apr 23 12:34:57 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 23 Apr 2025 12:34:57 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
Message-ID: <wC-PuuevY2dFBy15TpLt0FkqUoYXjNlnVPJmr0Hs6fI=.3a0cf1aa-cf4f-4535-94ef-4581e36bbe20@github.com>

On Wed, 23 Apr 2025 12:13:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
> 
> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
> 
> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.

@jayathirthrao 
Does this change has any effect on Linux platform ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1791#issuecomment-2824133184

From jdv at openjdk.org  Wed Apr 23 12:40:47 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Apr 2025 12:40:47 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <wC-PuuevY2dFBy15TpLt0FkqUoYXjNlnVPJmr0Hs6fI=.3a0cf1aa-cf4f-4535-94ef-4581e36bbe20@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
 <wC-PuuevY2dFBy15TpLt0FkqUoYXjNlnVPJmr0Hs6fI=.3a0cf1aa-cf4f-4535-94ef-4581e36bbe20@github.com>
Message-ID: <OjQZxVgva5DYHKbYP73cebIYp7BnvJYfUxUSD5B-xmk=.50c8dc6d-505d-4c0a-ad70-142e3c44de8c@github.com>

On Wed, 23 Apr 2025 12:31:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
>> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
>> 
>> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
>> 
>> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.
>
> @jayathirthrao 
> Does this change has any effect on Linux platform ?

@arapte I have run all headful system tests in CI on linux and it is green.
This change will effect all platforms where OpenGL will be used, but not using 0.0 in pow() on all platforms is right thing to do.

Just to be sure i will also run Ensemble8 in Linux and update.

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

PR Comment: https://git.openjdk.org/jfx/pull/1791#issuecomment-2824148822

From jbhaskar at openjdk.org  Wed Apr 23 12:47:08 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 12:47:08 GMT
Subject: [jfx24u] RFR: 8354876: Update SQLite to 3.49.1
Message-ID: <RUze1bOLTgfeoUzsFRiQMIuBVy9-4biMG49YBQxgjDY=.a39720b5-8fd8-4290-ab37-5b39a840c097@github.com>

A clean backport to jfx24u, only files path in the patch has been has been updated. The patch is sqlite upgrade as in mainline.

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

Commit messages:
 - Backport 46b36fe432aab81468df44344ab5e36aa31c5f47

Changes: https://git.openjdk.org/jfx24u/pull/23/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354876
  Stats: 13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod
  Patch: https://git.openjdk.org/jfx24u/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/23/head:pull/23

PR: https://git.openjdk.org/jfx24u/pull/23

From kcr at openjdk.org  Wed Apr 23 13:23:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 13:23:07 GMT
Subject: [jfx24u] Integrated: 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: <PfOOhr4FYOU78R15NJofXWmH_i6VhVu9YL75nyeH91o=.39935669-c0dd-4a09-a475-b65aa1909e6f@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.

This pull request has now been integrated.

Changeset: 1cd8c459
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/1cd8c4593706b6d7d36c7ae56922d77234e7e187
Stats:     15 lines in 2 files changed: 11 ins; 0 del; 4 mod

8354337: GHA: Windows build fails with chmod permission error

Backport-of: 8a61dd2b808e1fa691150d01eafd2697d0d1c56d

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

PR: https://git.openjdk.org/jfx24u/pull/20

From kcr at openjdk.org  Wed Apr 23 13:23:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 13:23:10 GMT
Subject: [jfx24u] Integrated: 8354318: freetype.c: compilation error:
 'incompatible pointer type' with gcc 14
In-Reply-To: <UKkQHzzQIC7hiFccO7aGUzTEr02KVLN3jBJ4cp431KQ=.1910887b-9b4d-4518-a34b-a63333772a5d@github.com>
References: <UKkQHzzQIC7hiFccO7aGUzTEr02KVLN3jBJ4cp431KQ=.1910887b-9b4d-4518-a34b-a63333772a5d@github.com>
Message-ID: <0rtTMVa5xgSk5O8JdffwDLqUsSeU7Gq9kqInmk06oy4=.3e93b7eb-60b6-4cca-a35d-d0ab4d68a733@github.com>

On Mon, 14 Apr 2025 17:40:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of "incompatible pointer type" fix to jfx24u

This pull request has now been integrated.

Changeset: 54bd8aaf
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/54bd8aaf249afdf59f9d870b9020ce6822ca84cf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8354318: freetype.c: compilation error: 'incompatible pointer type' with gcc 14

Backport-of: 5a897ab7017107471528ab527dac505d2e33aca9

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

PR: https://git.openjdk.org/jfx24u/pull/21

From kcr at openjdk.org  Wed Apr 23 13:23:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 13:23:54 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <wC-PuuevY2dFBy15TpLt0FkqUoYXjNlnVPJmr0Hs6fI=.3a0cf1aa-cf4f-4535-94ef-4581e36bbe20@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
 <wC-PuuevY2dFBy15TpLt0FkqUoYXjNlnVPJmr0Hs6fI=.3a0cf1aa-cf4f-4535-94ef-4581e36bbe20@github.com>
Message-ID: <oizsZeqQX4YBOqosRX269MK-YaFnc2ob-vH22zM99-k=.06f0b5e4-05b3-4a57-ac31-205c6942bff8@github.com>

On Wed, 23 Apr 2025 12:31:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
>> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
>> 
>> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
>> 
>> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.
>
> @jayathirthrao 
> Does this change has any effect on Linux platform ?

Reviewers: @arapte @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1791#issuecomment-2824284564

From jbhaskar at openjdk.org  Wed Apr 23 13:27:59 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 13:27:59 GMT
Subject: [jfx24u] Integrated: 8354876: Update SQLite to 3.49.1
In-Reply-To: <RUze1bOLTgfeoUzsFRiQMIuBVy9-4biMG49YBQxgjDY=.a39720b5-8fd8-4290-ab37-5b39a840c097@github.com>
References: <RUze1bOLTgfeoUzsFRiQMIuBVy9-4biMG49YBQxgjDY=.a39720b5-8fd8-4290-ab37-5b39a840c097@github.com>
Message-ID: <8AbJ-SNZ5X0bCvyJrBS94Cdvz3RHSIaw1_jLG28tkkk=.1ab2f059-a5f9-42a7-a37d-423a4f6a880e@github.com>

On Wed, 23 Apr 2025 12:42:19 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx24u, only files path in the patch has been has been updated. The patch is sqlite upgrade as in mainline.

This pull request has now been integrated.

Changeset: 476fbad1
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/476fbad19abd488e0892aee542346c3936b0410f
Stats:     13661 lines in 2 files changed: 7174 ins; 1311 del; 5176 mod

8354876: Update SQLite to 3.49.1

Backport-of: 46b36fe432aab81468df44344ab5e36aa31c5f47

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

PR: https://git.openjdk.org/jfx24u/pull/23

From kcr at openjdk.org  Wed Apr 23 13:35:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 13:35:49 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
Message-ID: <FD89pC8CD0ndSPgKzrferx2atvY8kzaCONBQolw9Zuc=.e3698552-8930-485c-8293-7c74364f5cd0@github.com>

On Wed, 23 Apr 2025 12:13:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
> 
> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
> 
> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.

LGTM. On my macOS 14.x M1 system, the re-enabled test fails without the fix and passes with the fix. It looks visually correct now.

I didn't test it on Linux, so I'll rely on others to do that.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1791#pullrequestreview-2787346146

From arapte at openjdk.org  Wed Apr 23 14:02:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 23 Apr 2025 14:02:50 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
Message-ID: <P9a6HmuR-mDIvRzcIynlJrtxKfUk76pRpJwjtfUM5-Y=.48275ed8-b106-4fe3-97ab-3e638e49b04d@github.com>

On Wed, 23 Apr 2025 12:13:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
> 
> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
> 
> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.

LGTM. Tested on mac and windows(with es2 pipeline) platform.
Shall rely @jayathirthrao for Linux sanity testing.

Please wait for 24 hours before integrating.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1791#pullrequestreview-2787441473
PR Comment: https://git.openjdk.org/jfx/pull/1791#issuecomment-2824412363

From jbhaskar at openjdk.org  Wed Apr 23 14:29:36 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 14:29:36 GMT
Subject: [jfx24u] RFR: 8352162: Update libxml2 to 2.13.8
Message-ID: <ytBkK6L0g0aMqGCEtvDectQBDDBi9uIcsFC5SO4aDhM=.7b16383a-262e-42e4-b374-93dc352a0b58@github.com>

A clean backport to jfx24u, only files path in the patch has been has been updated. The patch is for libxml and libxslt upgrade as in mainline.

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

Commit messages:
 - Backport 4df2326391b3528c48a4594ec9f3bb6fdde9a437

Changes: https://git.openjdk.org/jfx24u/pull/24/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=24&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352162
  Stats: 102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod
  Patch: https://git.openjdk.org/jfx24u/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/24/head:pull/24

PR: https://git.openjdk.org/jfx24u/pull/24

From andy.goryachev at oracle.com  Wed Apr 23 14:45:22 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 23 Apr 2025 14:45:22 +0000
Subject: [External] : Re: Unnecessary layouts; TLDR; new method
 "requestLocalLayout"
In-Reply-To: <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>
 <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>
Message-ID: <BYAPR10MB3013A52952E19794119E63BEE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>

Possibly related: https://bugs.openjdk.org/browse/JDK-8089992

-andy


From: John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, April 16, 2025 at 16:13
To: Nir Lisker <nlisker at gmail.com>, Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Unnecessary layouts; TLDR; new method "requestLocalLayout"

I tested this with several controls that were triggering layouts (like on cursor movements), and I saw no adverse effects.  Basically, any time you interact with a control and it triggers a full layout but its bounds didn't change (ie. nothing in the UI changed position or size) the full layout was unnecessary.

Most Skins/Controls do the simple thing of registering listeners on any properties that may change their appearance and calling requestLayout, while calling requestLayout should really be reserved for things that change their computeMin/Pref/Max values. If there were no changes in any of those, then the parent layout won't have changes either (and so on) so the final layout result will be the exact same as before, yet tens of thousands of calculations will have been done.  Because of how say HBox calculates its size, it also queries any siblings, which in turn may be containers...

The only things "stopping" layout propagation are things like scroll panes.  This is why TextArea is a lot less likely to trigger a layout all the way to the root vs TextField.

--John
On 16/04/2025 17:04, Nir Lisker wrote:
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<mailto: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<mailto:openjfx-dev-retn at openjdk.org>> on behalf of John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>>
Date: Monday, April 14, 2025 at 08:56
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto: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/20250423/abbb27cf/attachment-0001.htm>

From jdv at openjdk.org  Wed Apr 23 15:13:58 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Apr 2025 15:13:58 GMT
Subject: RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and later
In-Reply-To: <P9a6HmuR-mDIvRzcIynlJrtxKfUk76pRpJwjtfUM5-Y=.48275ed8-b106-4fe3-97ab-3e638e49b04d@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
 <P9a6HmuR-mDIvRzcIynlJrtxKfUk76pRpJwjtfUM5-Y=.48275ed8-b106-4fe3-97ab-3e638e49b04d@github.com>
Message-ID: <fr053_2EL34OcdjPxcjNFZ3mDQI5zAU9CHWkVx2STvw=.5df20307-1c51-4538-bce6-aa19d51f402b@github.com>

On Wed, 23 Apr 2025 13:59:43 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
>> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
>> 
>> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
>> 
>> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.
>
> Please wait for 24 hours before integrating.

> @arapte I have run all headful system tests in CI on linux and it is green. This change will effect all platforms where OpenGL will be used, but not using 0.0 in pow() on all platforms is right thing to do.
> 
> Just to be sure i will also run Ensemble8 in Linux and update.

I have verified Ensemble8 3D demos(played around with specular parameters in 3DSphere demo) on Ubuntu 24.04 and i don't see any issues.

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

PR Comment: https://git.openjdk.org/jfx/pull/1791#issuecomment-2824644604

From angorya at openjdk.org  Wed Apr 23 15:19:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 15:19:58 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>
 <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>
Message-ID: <PuiIPMKp1aNAV2YYtkOGkKqdwxwP3ojrLCeNnsN5i4Q=.b955c7df-9bab-4f0c-a25b-a5e5380f564b@github.com>

On Tue, 22 Apr 2025 23:10:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> It might, or perhaps it could be packaged into a jar so we can run single source files + library via JEP 458 `--class-path 'libs/*'` argument?
>> 
>> see "Using pre-compiled classes" section in
>> https://openjdk.org/jeps/458
>
> Unit tests already need to load the JavaFX modules, so I don't see how packaging it in a jar would help. All it would do it add one more thing to put on the path.

I meant the single-file manual tests, continuing discussion in https://github.com/openjdk/jfx/pull/1747

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056296082

From jbhaskar at openjdk.org  Wed Apr 23 15:23:50 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 23 Apr 2025 15:23:50 GMT
Subject: [jfx24u] Integrated: 8352162: Update libxml2 to 2.13.8
In-Reply-To: <ytBkK6L0g0aMqGCEtvDectQBDDBi9uIcsFC5SO4aDhM=.7b16383a-262e-42e4-b374-93dc352a0b58@github.com>
References: <ytBkK6L0g0aMqGCEtvDectQBDDBi9uIcsFC5SO4aDhM=.7b16383a-262e-42e4-b374-93dc352a0b58@github.com>
Message-ID: <nsyYHEzQ17k6eTxBCkf8sGG0NdZ6TMbztlOjp6uEVg0=.a5ebe13f-cdaf-45e1-b5f3-219658d64cfd@github.com>

On Wed, 23 Apr 2025 14:21:16 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx24u, only files path in the patch has been has been updated. The patch is for libxml and libxslt upgrade as in mainline.

This pull request has now been integrated.

Changeset: 72745a45
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/72745a45ca24a3cf0df46fe787c09b590251af1c
Stats:     102505 lines in 192 files changed: 18274 ins; 49395 del; 34836 mod

8352162: Update libxml2 to 2.13.8
8352164: Update libxslt to 1.1.43

Backport-of: 4df2326391b3528c48a4594ec9f3bb6fdde9a437

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

PR: https://git.openjdk.org/jfx24u/pull/24

From jdv at openjdk.org  Wed Apr 23 15:44:29 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Apr 2025 15:44:29 GMT
Subject: RFR: 8355413: Re-enable InitializeJavaFXLaunchTests on Xorg
Message-ID: <7Kkryes6c6232asMRr2Gpiliu4ZrhTBig1BWT2NbwUc=.0914a6c3-4ab2-4523-890d-b926b5f6e189@github.com>

As part of https://bugs.openjdk.org/browse/JDK-8353557, InitializeJavaFXLaunchTests were disabled as they were failing in Ubuntu24.04 VM and product issue https://bugs.openjdk.org/browse/JDK-8353644 was created.

But after verifying this test on actual Ubuntu 24.04 hardware it is identified that this test doesn't fail even multiple iterations. So we need to re-enable these tests.

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

Commit messages:
 - 8355413: [Xorg] Re-enable InitializeJavaFXLaunchTests on Linux

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

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

From john.hendrikx at gmail.com  Wed Apr 23 15:55:16 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 23 Apr 2025 17:55:16 +0200
Subject: [External] : Re: Unnecessary layouts; TLDR; new method
 "requestLocalLayout"
In-Reply-To: <BYAPR10MB3013A52952E19794119E63BEE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <3fa155b2-2709-4529-898a-79003efaedfb@gmail.com>
 <BYAPR10MB3013F25E77ED160D091E87A6E5BD2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CA+0ynh9e0ooe4eDOENKSkxbqP2RRZ2qj9-etM9KmypZXkijjKg@mail.gmail.com>
 <92d76b4e-f136-4f1c-897a-469eaac88857@gmail.com>
 <BYAPR10MB3013A52952E19794119E63BEE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <e82c615a-282c-43cb-a766-83698bc71b74@gmail.com>

Yeah, that's what I'm seeing, it happens on all kinds of actions, none
of which are triggering a resize that requires layout (like
opening/closing a TitledPane or resizing the whole Window).

--John

On 23/04/2025 16:45, Andy Goryachev wrote:
>
> Possibly related: https://bugs.openjdk.org/browse/JDK-8089992
>
> ?
>
> -andy
>
> ?
>
> ?
>
> *From: *John Hendrikx <john.hendrikx at gmail.com>
> *Date: *Wednesday, April 16, 2025 at 16:13
> *To: *Nir Lisker <nlisker at gmail.com>, Andy Goryachev
> <andy.goryachev at oracle.com>
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: Unnecessary layouts; TLDR; new method
> "requestLocalLayout"
>
> I tested this with several controls that were triggering layouts (like
> on cursor movements), and I saw no adverse effects.? Basically, any
> time you interact with a control and it triggers a full layout but its
> bounds didn't change (ie. nothing in the UI changed position or size)
> the full layout was unnecessary.
>
> Most Skins/Controls do the simple thing of registering listeners on
> any properties that may change their appearance and calling
> requestLayout, while calling requestLayout should really be reserved
> for things that change their computeMin/Pref/Max values. If there were
> no changes in any of those, then the parent layout won't have changes
> either (and so on) so the final layout result will be the exact same
> as before, yet tens of thousands of calculations will have been done.?
> Because of how say HBox calculates its size, it also queries any
> siblings, which in turn may be containers...
>
> The only things "stopping" layout propagation are things like scroll
> panes.? This is why TextArea is a lot less likely to trigger a layout
> all the way to the root vs TextField.
>
> --John
>
> On 16/04/2025 17:04, Nir Lisker wrote:
>
>     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/20250423/b3ab394e/attachment-0001.htm>

From kcr at openjdk.org  Wed Apr 23 16:21:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 16:21:50 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <PuiIPMKp1aNAV2YYtkOGkKqdwxwP3ojrLCeNnsN5i4Q=.b955c7df-9bab-4f0c-a25b-a5e5380f564b@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>
 <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>
 <PuiIPMKp1aNAV2YYtkOGkKqdwxwP3ojrLCeNnsN5i4Q=.b955c7df-9bab-4f0c-a25b-a5e5380f564b@github.com>
Message-ID: <shzDnmtU61o8a_48RJsTDi9EqEm_q7UbTP9IBOzGM4w=.29d5a2f7-d90b-48af-a158-01fef594eccb@github.com>

On Wed, 23 Apr 2025 15:17:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Unit tests already need to load the JavaFX modules, so I don't see how packaging it in a jar would help. All it would do it add one more thing to put on the path.
>
> I meant the single-file manual tests, continuing discussion in https://github.com/openjdk/jfx/pull/1747

Ah. I didn't get that from the context of this discussion, since we are discussing automated tests in this PR.

I'm not sure there is enough value in sharing utilities between manual tests and our JUnit-based automated tests for us to want to deal with the complexities that it would bring, but we can discuss that separately (not here).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056423946

From kcr at openjdk.org  Wed Apr 23 16:22:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 16:22:47 GMT
Subject: RFR: 8088343: Race condition in javafx.concurrent.Task::cancel
 [v3]
In-Reply-To: <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
Message-ID: <vfU9v-YuGim25Y8le5phnSfMsnbH6-PqeXn1Fd5cviY=.428afe91-2134-4413-b36b-6856831bbee6@github.com>

On Wed, 16 Apr 2025 20:28:14 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.
>> 
>> 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 five additional commits since the last revision:
> 
>  - cleanup
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - 8088343

LGTM. I instrumented the code and after a few test runs was able to spot a couple cases where this would have failed without the fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1769#pullrequestreview-2787949512

From kcr at openjdk.org  Wed Apr 23 16:39:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 16:39:59 GMT
Subject: RFR: 8355413: Re-enable InitializeJavaFXLaunchTests on Xorg
In-Reply-To: <7Kkryes6c6232asMRr2Gpiliu4ZrhTBig1BWT2NbwUc=.0914a6c3-4ab2-4523-890d-b926b5f6e189@github.com>
References: <7Kkryes6c6232asMRr2Gpiliu4ZrhTBig1BWT2NbwUc=.0914a6c3-4ab2-4523-890d-b926b5f6e189@github.com>
Message-ID: <F6-WWhed3WX0pKi0cxR7vHRIkQ72F_MzYrdnJcdMZWw=.f6c612c3-761b-43b4-aea3-278cb59ef566@github.com>

On Wed, 23 Apr 2025 15:27:23 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> As part of https://bugs.openjdk.org/browse/JDK-8353557, InitializeJavaFXLaunchTests were disabled as they were failing in Ubuntu24.04 VM and product issue https://bugs.openjdk.org/browse/JDK-8353644 was created.
> 
> But after verifying this test on actual Ubuntu 24.04 hardware it is identified that this test doesn't fail even after multiple iterations. So we need to re-enable these tests.

LGTM. As I noted in [this comment on JDK-8353644](https://bugs.openjdk.org/browse/JDK-8353644?focusedId=14772997&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14772997), I was able to run the test 1,000 times in a row with no failures on our Ubuntu 24.04 test system.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1792#pullrequestreview-2788048882

From crschnick at xpipe.io  Wed Apr 23 16:58:21 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 23 Apr 2025 18:58:21 +0200
Subject: ExpressionHelper thread-safety
Message-ID: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>

Hello,

I encountered a rare exception where adding listeners to an observable 
value might break when they are added concurrently. This is due to 
ExpressionHelper not being synchronized. I thought about how to fix this 
on my side, but it is very difficult to do. As this is not a typical 
platform thread issue, in my opinion it should be possible to add 
listeners to one observable value from any thread without having to 
think about any potential synchronization issues (which I can't solve 
other than just running everything on one thread).

Even worse, due to the size and array being two different variables and 
being incremented unsafely, once such a concurrent modification occurs, 
this invalid state will persist permanently and will cause exceptions on 
any further method call as well. The only solution is to restart the 
application.

This is how a stack trace looks like when this occurs:

21:25:38:840 - error: Index 2 out of bounds for length 2
java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
 ??? at 
com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
 ??? at 
com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
 ??? at 
com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
 ??? at 
javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
 ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
 ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
 ??? at javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
 ??? at 
io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
 ??? at 
io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
 ??? at 
io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
 ??? at 
io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
 ??? at java.lang.Iterable.forEach(Iterable.java:75)
 ??? at 
io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
 ??? at io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
 ??? at 
io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
 ??? at io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
 ??? at java.lang.Thread.run(Thread.java:1447)

21:25:38:847 - error: Index 3 out of bounds for length 2
java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 2
 ??? at 
com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
 ??? at 
com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
 ??? at 
com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
 ??? at 
javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
 ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
 ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
 ??? at javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
 ??? at 
io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
 ??? at 
io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
 ??? at 
io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
 ??? at 
io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
 ??? at 
io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
 ??? at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
 ??? at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
 ??? at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)

This full log goes up to index 50 out of bounds due to the recurring 
nature of this exception.

Looking at the implementation of ExpressionHelper, I don't see any harm 
in just synchronizing the methods, at least from my perspective. But I 
guess that is up to the developers to decide. The only real solution I 
have as an application developer is to perform all initialization on one 
thread or just hope that this error is rare enough, both of which aren't 
great options. So I hope that a potential synchronization of the 
ExpressionHelper methods can be considered.

Best
Christopher Schnick


From angorya at openjdk.org  Wed Apr 23 17:17:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 17:17:49 GMT
Subject: RFR: 8088343: Race condition in javafx.concurrent.Task::cancel
 [v3]
In-Reply-To: <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
Message-ID: <nlAqVPu0MLRaeHqlJbBp9EC2wsH2r1drURoIRIQtaTc=.9adc94e1-9e48-469f-8dd8-41fc25aa29c7@github.com>

On Wed, 16 Apr 2025 20:28:14 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.
>> 
>> 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 five additional commits since the last revision:
> 
>  - cleanup
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - 8088343

@arapte or @Ziad-Mid : could one of you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1769#issuecomment-2824994772

From angorya at openjdk.org  Wed Apr 23 18:30:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 18:30:59 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <w5PP3-aDUpXD6H75z_PBAEt1wV7FrR3Lb2K4IpRYEVA=.ac58d259-5a25-4557-ae4f-84685e30b449@github.com>

On Tue, 22 Apr 2025 21:37:38 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 307:
> 
>> 305:         control.copy();
>> 306:         String s = Clipboard.getSystemClipboard().getString();
>> 307:         assertEquals("ax", s);
> 
> Suggestion: expand this to check various selection segments and boundary conditions (e.g., test copying when the selection has a single character at the beginning, missing, and end) as well as no selection (clipboard string should be empty).

Kevin, I am not entirely sure what you mean by `selection has a single character at the beginning, missing, and end`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056668003

From angorya at openjdk.org  Wed Apr 23 18:40:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 18:40:59 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <QjyDNN7FcPmtfActfcLQWaUt0Cg14ykh1OTaBBy5VLY=.f3bf29f9-62e8-4c63-aa0e-09a04c0888b2@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <QjyDNN7FcPmtfActfcLQWaUt0Cg14ykh1OTaBBy5VLY=.f3bf29f9-62e8-4c63-aa0e-09a04c0888b2@github.com>
Message-ID: <F3ip3laDa2At9hvSwayAA2czxLg--FYvhiHplNwbCjw=.fef859e6-14cb-4ab1-a498-dfd36d08b18f@github.com>

On Tue, 22 Apr 2025 22:48:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 410:
>> 
>>> 408:         control.setModel(null);
>>> 409:         // on second through, maybe this should return null
>>> 410:         assertEquals(TextPos.ZERO, control.getParagraphEnd(0));
>> 
>> Are you keeping a list of such API questions?
>> 
>> In this case, I would think that asking for a paragraph that is out of range would throw IOOBE. What does control.getParagraph(N) do when N is out of range? This method should behave similarly.
>
> good point, let me think about it.

Agree with you - getParagraphEnd() should probably throw an IOOBE in case of a null model, or when the index goes beyond what the model supports, similarly to getParagraph().

I am going to leave this as is for this PR, and yes, I do keep track of the feedback and possible changes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056678066

From angorya at openjdk.org  Wed Apr 23 18:41:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 18:41:02 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <jmPhRtd_1PjZsVCz8ZNUXMAQOJB8nkISAtqUbkK8hJo=.e9c600d9-0da0-462c-8093-979f0823bf3f@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <jmPhRtd_1PjZsVCz8ZNUXMAQOJB8nkISAtqUbkK8hJo=.e9c600d9-0da0-462c-8093-979f0823bf3f@github.com>
Message-ID: <0SWII4E_OQ1B4VReq4iR3NrEbYB1CLDKg5prgPLXQto=.82cc863e-a76e-45f4-a49a-a71da70d8500@github.com>

On Tue, 22 Apr 2025 23:12:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 466:
>> 
>>> 464: 
>>> 465:     @Test
>>> 466:     public void modelChangeClearsSelection() {
>> 
>> Since the actual data is sorted in the model, it might also be good to test that a model change clears all of the text that you have previously appended (in another test method).
>
>> Since the actual data is sorted
> 
> Typo, I meant "stored"

each test starts with a freshly created model, but it's a good idea to add a check for the content.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056682427

From angorya at openjdk.org  Wed Apr 23 18:41:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 18:41:01 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
Message-ID: <imU32V_CoQK6dM_w4d3sCoeUc5NYUX0XK2JuyX_cnls=.d21f390a-3306-4373-b0fa-d5f992e2a30c@github.com>

On Tue, 22 Apr 2025 21:44:33 GMT, Kevin Rushforth <kcr 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 27 commits:
>> 
>>  - rm junit4
>>  - 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/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
>>  - ... and 17 more: https://git.openjdk.org/jfx/compare/703a9a90...0fb16fdc
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 444:
> 
>> 442: 
>> 443: //    @Test
>> 444: //    public void insertLineBreak() {
> 
> Why is this commented out? A comment explaining why would be good. Or if there is a functional bug that prevents it, uncomment it and skip it with `@Disabled("JDK-8888888")`.

created https://bugs.openjdk.org/browse/JDK-8355415

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056679501

From kevin.rushforth at oracle.com  Wed Apr 23 18:41:23 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 23 Apr 2025 11:41:23 -0700
Subject: ExpressionHelper thread-safety
In-Reply-To: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
Message-ID: <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>

This came up most recently in the discussion of 
https://github.com/openjdk/jfx/pull/1697

As noted by you and in that PR, properties are not thread-safe. If two 
threads add a listener concurrently, or if one thread adds a listener 
while and another thread notifies the listeners, it is likely to fail.

So the question is: Is it worth doing something about this? And if so, 
how far do we go?

Making the add/remove listeners operations on ExpressionHelper (and 
related classes?) thread-safe so that listeners could be added or 
removed on any thread concurrently with each other and with the 
operation off firing a listener probably wouldn't be too hard or have 
much downside (the performance impact should be negligible and it is 
unlikely to cause a deadlock).

You still wouldn't be able to modify a property on more than one thread, 
nor control the thread on which listeners are notified (they are 
notified on the thread that mutates the property), so it won't magically 
solve all your threading issues; and you still would need to deal with 
the fact that your listener can be called on a different thread than the 
one which added it.

I'd like to hear from Andy, John, and others as to whether they think 
there is value in providing partial thread-safety for the add/remove 
listener methods of properties.

-- Kevin


On 4/23/2025 9:58 AM, Christopher Schnick wrote:
> Hello,
>
> I encountered a rare exception where adding listeners to an observable 
> value might break when they are added concurrently. This is due to 
> ExpressionHelper not being synchronized. I thought about how to fix 
> this on my side, but it is very difficult to do. As this is not a 
> typical platform thread issue, in my opinion it should be possible to 
> add listeners to one observable value from any thread without having 
> to think about any potential synchronization issues (which I can't 
> solve other than just running everything on one thread).
>
> Even worse, due to the size and array being two different variables 
> and being incremented unsafely, once such a concurrent modification 
> occurs, this invalid state will persist permanently and will cause 
> exceptions on any further method call as well. The only solution is to 
> restart the application.
>
> This is how a stack trace looks like when this occurs:
>
> 21:25:38:840 - error: Index 2 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for 
> length 2
> ??? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> ??? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> ??? at 
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> ??? at 
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> ??? at 
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> ??? at 
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> ??? at 
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> ??? at 
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> ??? at 
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
> ??? at java.lang.Iterable.forEach(Iterable.java:75)
> ??? at 
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
> ??? at 
> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
> ??? at 
> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
> ??? at io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
> ??? at java.lang.Thread.run(Thread.java:1447)
>
> 21:25:38:847 - error: Index 3 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for 
> length 2
> ??? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> ??? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> ??? at 
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> ??? at 
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> ??? at 
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> ??? at 
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> ??? at 
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> ??? at 
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> ??? at 
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
> ??? at 
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
> ??? at 
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
> ??? at 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
> ??? at 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>
> This full log goes up to index 50 out of bounds due to the recurring 
> nature of this exception.
>
> Looking at the implementation of ExpressionHelper, I don't see any 
> harm in just synchronizing the methods, at least from my perspective. 
> But I guess that is up to the developers to decide. The only real 
> solution I have as an application developer is to perform all 
> initialization on one thread or just hope that this error is rare 
> enough, both of which aren't great options. So I hope that a potential 
> synchronization of the ExpressionHelper methods can be considered.
>
> Best
> Christopher Schnick
>


From nlisker at gmail.com  Wed Apr 23 18:54:48 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 23 Apr 2025 21:54:48 +0300
Subject: ExpressionHelper thread-safety
In-Reply-To: <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
Message-ID: <CA+0ynh_1qfMPoEG_qeo-Q2+43=3ix3v0mh=RVajKLc_rBS8ydw@mail.gmail.com>

John is replacing some of the ExpressionHelper uses (properties and
bindings) through https://github.com/openjdk/jfx/pull/1081. It's still
single threaded, but I think the new implementation there should be the
center point of this discussion.

On Wed, Apr 23, 2025 at 9:41?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> This came up most recently in the discussion of
> https://github.com/openjdk/jfx/pull/1697
>
> As noted by you and in that PR, properties are not thread-safe. If two
> threads add a listener concurrently, or if one thread adds a listener
> while and another thread notifies the listeners, it is likely to fail.
>
> So the question is: Is it worth doing something about this? And if so,
> how far do we go?
>
> Making the add/remove listeners operations on ExpressionHelper (and
> related classes?) thread-safe so that listeners could be added or
> removed on any thread concurrently with each other and with the
> operation off firing a listener probably wouldn't be too hard or have
> much downside (the performance impact should be negligible and it is
> unlikely to cause a deadlock).
>
> You still wouldn't be able to modify a property on more than one thread,
> nor control the thread on which listeners are notified (they are
> notified on the thread that mutates the property), so it won't magically
> solve all your threading issues; and you still would need to deal with
> the fact that your listener can be called on a different thread than the
> one which added it.
>
> I'd like to hear from Andy, John, and others as to whether they think
> there is value in providing partial thread-safety for the add/remove
> listener methods of properties.
>
> -- Kevin
>
>
> On 4/23/2025 9:58 AM, Christopher Schnick wrote:
> > Hello,
> >
> > I encountered a rare exception where adding listeners to an observable
> > value might break when they are added concurrently. This is due to
> > ExpressionHelper not being synchronized. I thought about how to fix
> > this on my side, but it is very difficult to do. As this is not a
> > typical platform thread issue, in my opinion it should be possible to
> > add listeners to one observable value from any thread without having
> > to think about any potential synchronization issues (which I can't
> > solve other than just running everything on one thread).
> >
> > Even worse, due to the size and array being two different variables
> > and being incremented unsafely, once such a concurrent modification
> > occurs, this invalid state will persist permanently and will cause
> > exceptions on any further method call as well. The only solution is to
> > restart the application.
> >
> > This is how a stack trace looks like when this occurs:
> >
> > 21:25:38:840 - error: Index 2 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> > length 2
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> >     at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> >     at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> >     at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> >     at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> >     at
> >
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> >     at
> >
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> >     at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> >     at
> >
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
> >     at java.lang.Iterable.forEach(Iterable.java:75)
> >     at
> >
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
> >     at
> > io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
> >     at
> > io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
> >     at io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
> >     at java.lang.Thread.run(Thread.java:1447)
> >
> > 21:25:38:847 - error: Index 3 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
> > length 2
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> >     at
> >
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> >     at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> >     at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> >     at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> >     at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> >     at
> >
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> >     at
> >
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> >     at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> >     at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
> >     at
> >
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
> >     at
> >
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
> >     at
> >
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
> >     at
> >
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
> >
> > This full log goes up to index 50 out of bounds due to the recurring
> > nature of this exception.
> >
> > Looking at the implementation of ExpressionHelper, I don't see any
> > harm in just synchronizing the methods, at least from my perspective.
> > But I guess that is up to the developers to decide. The only real
> > solution I have as an application developer is to perform all
> > initialization on one thread or just hope that this error is rare
> > enough, both of which aren't great options. So I hope that a potential
> > synchronization of the ExpressionHelper methods can be considered.
> >
> > Best
> > Christopher Schnick
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250423/09238205/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Apr 23 18:59:44 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 23 Apr 2025 18:59:44 +0000
Subject: ExpressionHelper thread-safety
In-Reply-To: <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
Message-ID: <BYAPR10MB30131847B13AD54A4257017CE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>

Even though JavaFX explicitly permits creating Nodes and Scenes in a thread other than the Application Thread, I think it is still a bad idea, and I would strongly suggest against doing so.  The code might work - initially - but you will soon discover that it presents a constant source of issues, especially after the application is deployed.

I would also question the value of such a design.  How many milliseconds is being saved by trying to instantiate Nodes in a background thread?  If you create only a few objects, there is absolutely no benefit (and a huge maintenance burden), but if there are too many objects created then maybe one is doing something wrong, perhaps instead one should try to create things in batches?

So my recommendation would remain the same: please don't.  Always access JavaFX objects from the Application Thread.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Wednesday, April 23, 2025 at 11:41
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: ExpressionHelper thread-safety
This came up most recently in the discussion of
https://github.com/openjdk/jfx/pull/1697

As noted by you and in that PR, properties are not thread-safe. If two
threads add a listener concurrently, or if one thread adds a listener
while and another thread notifies the listeners, it is likely to fail.

So the question is: Is it worth doing something about this? And if so,
how far do we go?

Making the add/remove listeners operations on ExpressionHelper (and
related classes?) thread-safe so that listeners could be added or
removed on any thread concurrently with each other and with the
operation off firing a listener probably wouldn't be too hard or have
much downside (the performance impact should be negligible and it is
unlikely to cause a deadlock).

You still wouldn't be able to modify a property on more than one thread,
nor control the thread on which listeners are notified (they are
notified on the thread that mutates the property), so it won't magically
solve all your threading issues; and you still would need to deal with
the fact that your listener can be called on a different thread than the
one which added it.

I'd like to hear from Andy, John, and others as to whether they think
there is value in providing partial thread-safety for the add/remove
listener methods of properties.

-- Kevin


On 4/23/2025 9:58 AM, Christopher Schnick wrote:
> Hello,
>
> I encountered a rare exception where adding listeners to an observable
> value might break when they are added concurrently. This is due to
> ExpressionHelper not being synchronized. I thought about how to fix
> this on my side, but it is very difficult to do. As this is not a
> typical platform thread issue, in my opinion it should be possible to
> add listeners to one observable value from any thread without having
> to think about any potential synchronization issues (which I can't
> solve other than just running everything on one thread).
>
> Even worse, due to the size and array being two different variables
> and being incremented unsafely, once such a concurrent modification
> occurs, this invalid state will persist permanently and will cause
> exceptions on any further method call as well. The only solution is to
> restart the application.
>
> This is how a stack trace looks like when this occurs:
>
> 21:25:38:840 - error: Index 2 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> length 2
>     at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>     at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>     at
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>     at
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>     at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>     at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>     at
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>     at
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>     at
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>     at
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>     at
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>     at java.lang.Iterable.forEach(Iterable.java:75)
>     at
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>     at
> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>     at
> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>     at io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>     at java.lang.Thread.run(Thread.java:1447)
>
> 21:25:38:847 - error: Index 3 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
> length 2
>     at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>     at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>     at
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>     at
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>     at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>     at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>     at
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>     at
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>     at
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>     at
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>     at
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>     at
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>     at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>     at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>     at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>
> This full log goes up to index 50 out of bounds due to the recurring
> nature of this exception.
>
> Looking at the implementation of ExpressionHelper, I don't see any
> harm in just synchronizing the methods, at least from my perspective.
> But I guess that is up to the developers to decide. The only real
> solution I have as an application developer is to perform all
> initialization on one thread or just hope that this error is rare
> enough, both of which aren't great options. So I hope that a potential
> synchronization of the ExpressionHelper methods can be considered.
>
> Best
> Christopher Schnick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250423/5ca0ed06/attachment-0001.htm>

From nlisker at openjdk.org  Wed Apr 23 18:59:56 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 23 Apr 2025 18:59:56 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v16]
In-Reply-To: <Q2zWwhM_tIqcQK0MonInPUw_FI7QzO4Wd7W-GOThW24=.4451b172-ab70-4842-81a8-fdd5d0be0e16@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <Q2zWwhM_tIqcQK0MonInPUw_FI7QzO4Wd7W-GOThW24=.4451b172-ab70-4842-81a8-fdd5d0be0e16@github.com>
Message-ID: <6wlPeyU1OuX1uqJkddZylMe4XYXZRoDgC0_osKWsO9A=.e713be9b-b6c4-4ef5-853b-1d3f9ebe864c@github.com>

On Wed, 12 Mar 2025 14:40:01 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change StackOverflowException to warning log
>  - Support keeping last message in Logging helper

I'm bogged down recently. I went over about 1/3 of the test code, will continue when I can.

If Kevin approves this so will I. The tests can be reviewed later too.

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

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2825235555

From crschnick at xpipe.io  Wed Apr 23 19:04:55 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 23 Apr 2025 21:04:55 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <BYAPR10MB30131847B13AD54A4257017CE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
 <BYAPR10MB30131847B13AD54A4257017CE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <490a90af-32f8-41ed-9e8e-990286f4cba7@xpipe.io>

The javafx.beans package for me at least isn't necessarily bound to 
JavaFX nodes. In our case, we use observable values for more than just 
for JavaFX nodes. They are useful on their own. Obviously in most cases 
they are used in relation to nodes, but in our case we instantiate 
properties and add listeners (across multiple threads) before the 
Platform is even started.

On 23/04/2025 20:59, Andy Goryachev wrote:
>
> Even though JavaFX explicitly permits creating Nodes and Scenes in a 
> thread other than the Application Thread, I think it is still a bad 
> idea, and I would strongly suggest against doing so.? The code might 
> work - initially - but you will soon discover that it presents a 
> constant source of issues, especially after the application is deployed.
>
> I would also question the value of such a design.? How many 
> milliseconds is being saved by trying to instantiate Nodes in a 
> background thread?? If you create only a few objects, there is 
> absolutely no benefit (and a huge maintenance burden), but if there 
> are too many objects created then maybe one is doing something wrong, 
> perhaps instead one should try to create things in batches?
>
> So my recommendation would remain the same: please don't. Always 
> access JavaFX objects from the Application Thread.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Wednesday, April 23, 2025 at 11:41
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: ExpressionHelper thread-safety
>
> This came up most recently in the discussion of
> https://github.com/openjdk/jfx/pull/1697
>
> As noted by you and in that PR, properties are not thread-safe. If two
> threads add a listener concurrently, or if one thread adds a listener
> while and another thread notifies the listeners, it is likely to fail.
>
> So the question is: Is it worth doing something about this? And if so,
> how far do we go?
>
> Making the add/remove listeners operations on ExpressionHelper (and
> related classes?) thread-safe so that listeners could be added or
> removed on any thread concurrently with each other and with the
> operation off firing a listener probably wouldn't be too hard or have
> much downside (the performance impact should be negligible and it is
> unlikely to cause a deadlock).
>
> You still wouldn't be able to modify a property on more than one thread,
> nor control the thread on which listeners are notified (they are
> notified on the thread that mutates the property), so it won't magically
> solve all your threading issues; and you still would need to deal with
> the fact that your listener can be called on a different thread than the
> one which added it.
>
> I'd like to hear from Andy, John, and others as to whether they think
> there is value in providing partial thread-safety for the add/remove
> listener methods of properties.
>
> -- Kevin
>
>
> On 4/23/2025 9:58 AM, Christopher Schnick wrote:
> > Hello,
> >
> > I encountered a rare exception where adding listeners to an observable
> > value might break when they are added concurrently. This is due to
> > ExpressionHelper not being synchronized. I thought about how to fix
> > this on my side, but it is very difficult to do. As this is not a
> > typical platform thread issue, in my opinion it should be possible to
> > add listeners to one observable value from any thread without having
> > to think about any potential synchronization issues (which I can't
> > solve other than just running everything on one thread).
> >
> > Even worse, due to the size and array being two different variables
> > and being incremented unsafely, once such a concurrent modification
> > occurs, this invalid state will persist permanently and will cause
> > exceptions on any further method call as well. The only solution is to
> > restart the application.
> >
> > This is how a stack trace looks like when this occurs:
> >
> > 21:25:38:840 - error: Index 2 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> > length 2
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> > ??? at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> > ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> > ??? at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> > ??? at
> > 
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> > ??? at
> > 
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> > ??? at
> > 
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> > ??? at
> > 
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
> > ??? at java.lang.Iterable.forEach(Iterable.java:75)
> > ??? at
> > 
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
> > ??? at
> > io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
> > ??? at
> > io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
> > ??? at 
> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
> > ??? at java.lang.Thread.run(Thread.java:1447)
> >
> > 21:25:38:847 - error: Index 3 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
> > length 2
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> > ??? at
> > 
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> > ??? at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> > ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> > ??? at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> > ??? at
> > 
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> > ??? at
> > 
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> > ??? at
> > 
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> > ??? at
> > 
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
> > ??? at
> > 
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
> > ??? at
> > 
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
> > ??? at
> > 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
> > ??? at
> > 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
> >
> > This full log goes up to index 50 out of bounds due to the recurring
> > nature of this exception.
> >
> > Looking at the implementation of ExpressionHelper, I don't see any
> > harm in just synchronizing the methods, at least from my perspective.
> > But I guess that is up to the developers to decide. The only real
> > solution I have as an application developer is to perform all
> > initialization on one thread or just hope that this error is rare
> > enough, both of which aren't great options. So I hope that a potential
> > synchronization of the ExpressionHelper methods can be considered.
> >
> > Best
> > Christopher Schnick
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250423/ac979dd9/attachment-0001.htm>

From angorya at openjdk.org  Wed Apr 23 19:15:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 19:15:52 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <L6cGfiq-yJZK-1gdU-xtH4X7l2tHAZem1boAOTUYb8A=.5aba23e4-6b8e-4e08-bb80-d247834a56f7@github.com>
 <7s7DTVzunwCj0Hknhg3RYWYS4gZ286R0WumoyFfJMk0=.3b1a3e91-7fbb-43e5-b190-e7fb3c494f70@github.com>
Message-ID: <gEnjRsavbC8v4b9C8t2PEIE6NWlUKmVPBHhYNMc7KZk=.ce00e089-23c3-4cca-9fd1-017570dba824@github.com>

On Tue, 22 Apr 2025 23:09:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> hmmm...  This pattern was copied from some other test.  We have 32 more instances of this pattern elsewhere.
>> 
>> I suspect it is not avoid declaring a checked exception.
>> What would you suggest?  Forward the `throwable` to `Thread.currentThread().getThreadGroup().uncaughtException(thread, throwable);` unconditionally?
>
> That's interesting that other tests do this. When re-throwing an exception you often need to special case checked exceptions (to wrap them so that the caller doesn't need to explicitly declare it), but the UncaughtExceptionHandler can handle both, so I don't know why it was done that way.
> 
> You might try just unconditionally forwarding all throwables, but not sure.

Turns out, this is required by junit framework to properly handle the failed tests.

If we pass all the Throwables to the thread group, then a RuntimeException thrown from a `@Test` does not mark the unit test as failed, though the stacktrace does appear in `stderr`;  a thrown `Error` will mark the test as failed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056736082

From mfox at openjdk.org  Wed Apr 23 19:28:49 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 23 Apr 2025 19:28:49 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
Message-ID: <0UFSkcUSbKhs9u-ySKzBrfatiRoQ6_o_78cRXeIENDY=.9cad33dc-1aef-4f7d-ba4e-2eed286690b6@github.com>

On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
>> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 9. It no longer keeps track of ge...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reenable RestoreSceneSizeTest (JDK-8353556)

Thanks for adding these tests. I'm currently tracking down two bugs on macOS that should have been caught a long time ago. Looks like these tests cover those cases (finally).

I will at least review and run the tests on macOS and report back. I might have time to run the tests on Windows 11. I don't have a Windows 10 box to test one.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2825313490

From angorya at openjdk.org  Wed Apr 23 19:31:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 19:31:16 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v9]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <ev9He2-dotoIolW1F2Q2ACGVZTvsbUDoUejtcv5mjFc=.eb61af30-b720-4457-8bdd-704c1f69e53b@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 29 commits:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - rm junit4
 - 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/master' into 8347359.rta.api.tests
 - ... and 19 more: https://git.openjdk.org/jfx/compare/d1fcca71...4f07d5f2

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

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=08
  Stats: 1445 lines in 10 files changed: 1386 ins; 29 del; 30 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 tsayao at openjdk.org  Wed Apr 23 20:38:50 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 23 Apr 2025 20:38:50 GMT
Subject: Integrated: 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: <AptoFhJFbO-AfCZKREUQNj4YvViIbAsW9oecWxkbdSc=.4e04c1a2-277a-48c4-85ec-e60ef04340a0@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)

This pull request has now been integrated.

Changeset: 1a129664
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1a129664c4a4c572c41209d4805abf0102cb21f1
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8354478: Improve StageStyle documentation

Reviewed-by: lkostyra, angorya

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

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

From kcr at openjdk.org  Wed Apr 23 20:42:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 20:42:54 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v8]
In-Reply-To: <w5PP3-aDUpXD6H75z_PBAEt1wV7FrR3Lb2K4IpRYEVA=.ac58d259-5a25-4557-ae4f-84685e30b449@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <EiWXQDlkfMwC8AyN4qhINPKfdpvPt4wX5WCaizcG2XU=.fdc6478f-f59a-4070-bd5b-8cdca8ddb1eb@github.com>
 <vCgB2XnpKmaGdOKgZVBUEduJxVQzR_zk8onWA0IP7Ak=.385287dc-b2be-4abe-8096-059fb6d3b023@github.com>
 <w5PP3-aDUpXD6H75z_PBAEt1wV7FrR3Lb2K4IpRYEVA=.ac58d259-5a25-4557-ae4f-84685e30b449@github.com>
Message-ID: <R7lS91kVxQIx-TANV-XDCe0bZdBbfyxGotl2G_yDLgk=.4c359f83-43a3-4274-8a22-7094b8df2219@github.com>

On Wed, 23 Apr 2025 18:28:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> beginning, missing, and end

Um, sorry about the typo. I'll blame auto-correct (although it's probably my fault).

I meant "beginning, **middle**, and end".

Currently you are testing `copy` with the entire paragraph selected. What I was trying to say is that another good test might be:


append("abcde");

clearSelection();
copy();
verify that clipboard contains ""

select(0);
copy();
verify that clipboard contains "a"

select(2);
copy();
verify that clipboard contains "c"

select(4);
copy();
verify that clipboard contains "e"

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056842147

From kcr at openjdk.org  Wed Apr 23 20:49:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 20:49:02 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v9]
In-Reply-To: <ev9He2-dotoIolW1F2Q2ACGVZTvsbUDoUejtcv5mjFc=.eb61af30-b720-4457-8bdd-704c1f69e53b@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <ev9He2-dotoIolW1F2Q2ACGVZTvsbUDoUejtcv5mjFc=.eb61af30-b720-4457-8bdd-704c1f69e53b@github.com>
Message-ID: <l41eBz2jbuu702NKWCrw7dGXpb9Q6Z2DjP_LC5d-Hrg=.3b5016e7-f904-4757-a1b7-b9a5479daa06@github.com>

On Wed, 23 Apr 2025 19:31:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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 29 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - rm junit4
>  - 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/master' into 8347359.rta.api.tests
>  - ... and 19 more: https://git.openjdk.org/jfx/compare/d1fcca71...4f07d5f2

LGTM. I'll reapprove if you make further changes.

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 322:

> 320: 
> 321:     @Disabled("JDK-8355415")
> 322:     // TODO combine with copy()

Minor: I might switch these two lines to keep all the annotations together.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1677#pullrequestreview-2788644840
PR Review Comment: https://git.openjdk.org/jfx/pull/1677#discussion_r2056846915

From angorya at openjdk.org  Wed Apr 23 21:23:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 21:23:31 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v10]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <-dSMR1xuvqw3sm-rZIZiWuE0tbiW8Btp7p-SIWzGwc0=.a92ba802-5754-42b7-a18e-5987db3077aa@github.com>

> Additional RichTextArea API tests.

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1677/files
  - new: https://git.openjdk.org/jfx/pull/1677/files/4f07d5f2..8d3f3ecd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=08-09

  Stats: 16 lines in 1 file changed: 13 ins; 1 del; 2 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 kcr at openjdk.org  Wed Apr 23 21:43:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Apr 2025 21:43:55 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v10]
In-Reply-To: <-dSMR1xuvqw3sm-rZIZiWuE0tbiW8Btp7p-SIWzGwc0=.a92ba802-5754-42b7-a18e-5987db3077aa@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <-dSMR1xuvqw3sm-rZIZiWuE0tbiW8Btp7p-SIWzGwc0=.a92ba802-5754-42b7-a18e-5987db3077aa@github.com>
Message-ID: <r0NcCWwS3ekDwkIuAb9sdOfxlG6JofLxgGl4MIsuqEk=.bc1da0d0-4a53-48a0-97cd-eb83a72bcb23@github.com>

On Wed, 23 Apr 2025 21:23:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Additional RichTextArea API tests.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1677#pullrequestreview-2788740501

From angorya at openjdk.org  Wed Apr 23 21:48:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Apr 2025 21:48:06 GMT
Subject: Integrated: 8347359: RichTextArea API Tests
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <krfababIriQyKUaDVxLiuqfrp-Nm1mXeeZG3d-9C2d4=.2f149414-e09b-4ec5-9aaf-07c12b557abd@github.com>

On Tue, 14 Jan 2025 19:44:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Additional RichTextArea API tests.

This pull request has now been integrated.

Changeset: 1b2f022d
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1b2f022d0c08d556d0decdf71d6e0c9d13dbe6f8
Stats:     1457 lines in 10 files changed: 1398 ins; 29 del; 30 mod

8347359: RichTextArea API Tests

Reviewed-by: kcr

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

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

From almatvee at openjdk.org  Wed Apr 23 23:30:21 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 23 Apr 2025 23:30:21 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
Message-ID: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>

- Fixed gcc 14 compiler errors.


../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
  178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
      | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      | |
      | GWeakRef **
../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
  274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);



../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
  202 | basedecoder_close_decoder(decoder);



../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
  548 | base->frame->data,
      | ~~~~~~~~~~~^~~~~~
      | |
      | uint8_t ** {aka unsigned char **}
../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}

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

Commit messages:
 - 8354336: gstclock.c: compilation error: 'incompatible pointer type' with gcc 14

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

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

From jhendrikx at openjdk.org  Thu Apr 24 00:04:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 24 Apr 2025 00:04:48 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
 <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
Message-ID: <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>

On Fri, 18 Apr 2025 14:39:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > So... you want me to add more styles so it then ends up looking like a correctly colored hyperlink?
> 
> No. I would like to retain the existing functionality where the styles alternate between `[ "details-button", "less" ]` and `[ "details-button", "more" ]`
> 
> If you look at the existing code, the setAll() in line 825 gets invoked at the moment the details button is created because the listener gets called in line 829.
> 
> So basically, your new code needs one change in (new) line 822:
> 
> `styleClasses.setAll("details-button");`
> 
> the rest is good.

Then we can close this, as that's what the original code does already.

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2825808010

From john.hendrikx at gmail.com  Thu Apr 24 01:56:23 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 24 Apr 2025 03:56:23 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
Message-ID: <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>

Hi,

I don't think adding synchronized in ExpressionHelper is going to really
solve your problem.? It will just move it elsewhere, but feel free to
let me know your exact scenario.? For now I will make some assumptions.

I'm assuming you are constructing UI's in a background thread, and this
UI requires listening to some global properties, like dark/light mode,
or any other configuration that must dynamically change your UI that's
basically global, or some global modeled state that can be independently
used, even without a UI.? It's certainly not an unreasonable scenario in
larger applications that may have a lot of configuration options -- I've
been there myself.? I usually call these "global" models; they're not
part of any specific piece of the user interface.? Feel free to let me
know your scenario.

I'm fine with UI's being constructed on background threads; anything
that could potentially take more than a millisecond SHOULD be done on a
background thread, as otherwise animations will stutter.? However, there
are several gotcha's with connecting a UI with?global models that expose
properties that you must be aware of:

## Listener Management

Any UI component that listens to?global properties must either:

a) unregister itself when the UI component is removed or closed (this
can be very difficult to track as FX has no #dispose method that will be
called)
b) use a weak listener (discouraged as this can lead to phantom call
backs of UI's you thought no longer existed until GC runs)
c) only register the listener when the UI is visible, and immediately
unregister when it becomes invisible (this can be largely automated with
the "when" method of ObservableValue)

Failing to do so means your UI component (including all its
children/parents as they refer to those) will never be garbage collected
as a global property is referring to it.

I highly recommend using the "when" construct here.? Basically, whenever
you want to listen to a global property from a UI component insert a
"when" statement:

?????? globalProperty.when(myComponentIsVisible).subscribe( ... ) or
addListener( ... )

Or:

?????? uiProperty.bind(globalProperty.when(myComponentIsVisible));

This results in listeners being registered on the FX thread just before
your UI becomes visible to the user.? It also removes the listeners on
the FX thread as soon as the UI becomes invisible.? See the
documentation for a good condition to use with when() for this.

## Global properties may call listeners at unexpected times!

When you?registered on such a property in a background thread, realize
that as soon as you do, you may get a callback from the FX thread.? At
that point in time, your presumed single threaded code that you are
constructing on your isolated thread is being run by two threads.? In
other words, you can get a callback from a global property halfway
during construction while your components may be in some half
constructed state.? As FX controls are never safe to use concurrently
(and neither will your listener code be) this can cause intermittent
problems.

All that said, let's say we do want to proceed to make listener
management a little bit safer and prevent ExpressionHelper from going
into a bad state.?

Your proposal to just synchronize the methods in ExpressionHelper will
be insufficient.? ExpressionHelper replaces itself on properties all the
time, meaning that having a single invalidation listener on a property
is a different ExpressionHelper instance then when that same property
has 2 invalidation listeners or say just a single change listener.? This
is done by properties like this (from ObjectPropertyBase):

@Override

publicvoidaddListener(InvalidationListener listener) {

helper= ExpressionHelper.addListener(helper, this, listener);

}

As you can see, the actual helper is getting replaced in certain cases
(it "morphs" from one internal type to another depending on what
listener?types and counts are registered).? That means that the first
call may be dealing with Helper#1, and the second call may also be
dealing with Helper#1 (blocking inside ExpressionHelper on a
synchronized block)... but the first call returns a new Helper,
including the new listener.? When then the second call runs that was
blocked, it will replace the Helper again but without knowledge of the
listener that was added by the first call.? This happens when going from
a single invalidation listener to two invalidation listeners -- it's a
different helper.

There are two ways around that; you could synchronize at an earlier
level before calling ExpressionHelper, adding synchronized to the above
method and similar methods, in all property/bindings and read only
property classes (about 20 orso).? Another is to?synchronize on the
property itself (which is passed as "this" in the above snippet).? That
still requires modifying 20 classes though as the "removeListener"
variant does not pass "this" currently, so it would need to be
explicitly passed for those as well to have something to synchronize on.

The PR which replaces
ExpressionHelper?(https://github.com/openjdk/jfx/pull/1081) faces
similar issues, but in that PR, "this" is passed already in all cases,
giving it something to synchronize on.? If that PR is integrated, then
offering thread safe adding/removal of listeners for all observable that
use the new solution can be done in one central location.

Perhaps it is worth doing; as Kevin mentioned, within FX itself we've
run into problems with registering listeners that required quite some
changes in many places.? A central fix may be preferable; however it
can't and won't be a full fix, as you still must deal with potential
callbacks coming in from another thread shortly after registering -- a
scenario that most developers will likely not be taking into account
while writing what they presume to be single threaded code...

--John


On 23/04/2025 18:58, Christopher Schnick wrote:
> Hello,
>
> I encountered a rare exception where adding listeners to an observable
> value might break when they are added concurrently. This is due to
> ExpressionHelper not being synchronized. I thought about how to fix
> this on my side, but it is very difficult to do. As this is not a
> typical platform thread issue, in my opinion it should be possible to
> add listeners to one observable value from any thread without having
> to think about any potential synchronization issues (which I can't
> solve other than just running everything on one thread).
>
> Even worse, due to the size and array being two different variables
> and being incremented unsafely, once such a concurrent modification
> occurs, this invalid state will persist permanently and will cause
> exceptions on any further method call as well. The only solution is to
> restart the application.
>
> This is how a stack trace looks like when this occurs:
>
> 21:25:38:840 - error: Index 2 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> length 2
> ??? at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> ??? at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> ??? at
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> ??? at
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> ??? at
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> ??? at
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> ??? at
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> ??? at
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> ??? at
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
> ??? at java.lang.Iterable.forEach(Iterable.java:75)
> ??? at
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
> ??? at
> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
> ??? at
> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
> ??? at io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
> ??? at java.lang.Thread.run(Thread.java:1447)
>
> 21:25:38:847 - error: Index 3 out of bounds for length 2
> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
> length 2
> ??? at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> ??? at
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> ??? at
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> ??? at
> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> ??? at
> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> ??? at
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> ??? at
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> ??? at
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> ??? at
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
> ??? at
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
> ??? at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
> ??? at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
> ??? at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>
> This full log goes up to index 50 out of bounds due to the recurring
> nature of this exception.
>
> Looking at the implementation of ExpressionHelper, I don't see any
> harm in just synchronizing the methods, at least from my perspective.
> But I guess that is up to the developers to decide. The only real
> solution I have as an application developer is to perform all
> initialization on one thread or just hope that this error is rare
> enough, both of which aren't great options. So I hope that a potential
> synchronization of the ExpressionHelper methods can be considered.
>
> Best
> Christopher Schnick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250424/dce500a4/attachment-0001.htm>

From john.hendrikx at gmail.com  Thu Apr 24 02:04:28 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 24 Apr 2025 04:04:28 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <CA+0ynh_1qfMPoEG_qeo-Q2+43=3ix3v0mh=RVajKLc_rBS8ydw@mail.gmail.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
 <CA+0ynh_1qfMPoEG_qeo-Q2+43=3ix3v0mh=RVajKLc_rBS8ydw@mail.gmail.com>
Message-ID: <cb7ce71d-004b-45a3-bd27-06388ada1c13@gmail.com>

In both cases only a partial fix can be applied that can ensure that at
a minimum the listener management doesn't get into a bad state.? The
issue of what happens when a callback occurs on a second thread while
instances are being manipulated on the first thread will remain.

The partial fix would involve synchronizing on the property, which can
be done in either all properties themselves, or in the helper (as they
are passed the property reference).? For ExpressionHelper,
removeListener currently doesn't pass the property reference, but it
could be added.? For the new PR, this is already the case.

--John

On 23/04/2025 20:54, Nir Lisker wrote:
> John is replacing some of the ExpressionHelper uses (properties and
> bindings) through https://github.com/openjdk/jfx/pull/1081. It's still
> single threaded, but I think the new implementation there should be
> the center point of this discussion.
>
> On Wed, Apr 23, 2025 at 9:41?PM Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
>
>     This came up most recently in the discussion of
>     https://github.com/openjdk/jfx/pull/1697
>
>     As noted by you and in that PR, properties are not thread-safe. If
>     two
>     threads add a listener concurrently, or if one thread adds a listener
>     while and another thread notifies the listeners, it is likely to fail.
>
>     So the question is: Is it worth doing something about this? And if
>     so,
>     how far do we go?
>
>     Making the add/remove listeners operations on ExpressionHelper (and
>     related classes?) thread-safe so that listeners could be added or
>     removed on any thread concurrently with each other and with the
>     operation off firing a listener probably wouldn't be too hard or have
>     much downside (the performance impact should be negligible and it is
>     unlikely to cause a deadlock).
>
>     You still wouldn't be able to modify a property on more than one
>     thread,
>     nor control the thread on which listeners are notified (they are
>     notified on the thread that mutates the property), so it won't
>     magically
>     solve all your threading issues; and you still would need to deal
>     with
>     the fact that your listener can be called on a different thread
>     than the
>     one which added it.
>
>     I'd like to hear from Andy, John, and others as to whether they think
>     there is value in providing partial thread-safety for the add/remove
>     listener methods of properties.
>
>     -- Kevin
>
>
>     On 4/23/2025 9:58 AM, Christopher Schnick wrote:
>     > Hello,
>     >
>     > I encountered a rare exception where adding listeners to an
>     observable
>     > value might break when they are added concurrently. This is due to
>     > ExpressionHelper not being synchronized. I thought about how to fix
>     > this on my side, but it is very difficult to do. As this is not a
>     > typical platform thread issue, in my opinion it should be
>     possible to
>     > add listeners to one observable value from any thread without
>     having
>     > to think about any potential synchronization issues (which I can't
>     > solve other than just running everything on one thread).
>     >
>     > Even worse, due to the size and array being two different variables
>     > and being incremented unsafely, once such a concurrent modification
>     > occurs, this invalid state will persist permanently and will cause
>     > exceptions on any further method call as well. The only solution
>     is to
>     > restart the application.
>     >
>     > This is how a stack trace looks like when this occurs:
>     >
>     > 21:25:38:840 - error: Index 2 out of bounds for length 2
>     > java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
>     > length 2
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>     > ??? at
>     >
>     javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>     > ??? at
>     javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>     > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>     > ??? at
>     > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>     > ??? at
>     >
>     io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>     > ??? at
>     >
>     io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>     > ??? at
>     >
>     io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>     > ??? at
>     >
>     io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>     > ??? at java.lang.Iterable.forEach(Iterable.java:75)
>     > ??? at
>     >
>     io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>     > ??? at
>     > io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>     > ??? at
>     >
>     io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>     > ??? at
>     io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>     > ??? at java.lang.Thread.run(Thread.java:1447)
>     >
>     > 21:25:38:847 - error: Index 3 out of bounds for length 2
>     > java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
>     > length 2
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>     > ??? at
>     >
>     com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>     > ??? at
>     >
>     javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>     > ??? at
>     javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>     > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>     > ??? at
>     > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>     > ??? at
>     >
>     io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>     > ??? at
>     >
>     io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>     > ??? at
>     >
>     io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>     > ??? at
>     >
>     io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>     > ??? at
>     >
>     io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>     > ??? at
>     >
>     com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>     > ??? at
>     >
>     com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>     > ??? at
>     >
>     com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>     >
>     > This full log goes up to index 50 out of bounds due to the
>     recurring
>     > nature of this exception.
>     >
>     > Looking at the implementation of ExpressionHelper, I don't see any
>     > harm in just synchronizing the methods, at least from my
>     perspective.
>     > But I guess that is up to the developers to decide. The only real
>     > solution I have as an application developer is to perform all
>     > initialization on one thread or just hope that this error is rare
>     > enough, both of which aren't great options. So I hope that a
>     potential
>     > synchronization of the ExpressionHelper methods can be considered.
>     >
>     > Best
>     > Christopher Schnick
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250424/c5038699/attachment.htm>

From john.hendrikx at gmail.com  Thu Apr 24 02:25:27 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 24 Apr 2025 04:25:27 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <BYAPR10MB30131847B13AD54A4257017CE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <e5a2f88b-9e3f-4aa0-b657-8ed44e2d29c3@oracle.com>
 <BYAPR10MB30131847B13AD54A4257017CE5BA2@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <d33a9b0d-adf0-4769-844f-09730e21255c@gmail.com>

On 23/04/2025 20:59, Andy Goryachev wrote:
>
> Even though JavaFX explicitly permits creating Nodes and Scenes in a
> thread other than the Application Thread, I think it is still a bad
> idea, and I would strongly suggest against doing so.? The code might
> work - initially - but you will soon discover that it presents a
> constant source of issues, especially after the application is deployed.
>
> ?
>
> I would also question the value of such a design.? How many
> milliseconds is being saved by trying to instantiate Nodes in a
> background thread?? If you create only a few objects, there is
> absolutely no benefit (and a huge maintenance burden), but if there
> are too many objects created then maybe one is doing something wrong,
> perhaps instead one should try to create things in batches?
>
The question isn't so much how much milliseconds it saves; the question
is, do you want to burden the FX thread with any multi-millisecond
action, including construction of a big component (like a new Tab full
of controls, or an entire Window)?? The answer to that should be a clear
no; anything that takes more than few milliseconds will mean stuttering
animations as frames will get dropped.?

Constructing components in a background thread is perfectly fine; you
however should NOT connect these components on the background thread to
any properties that may receive FX thread callbacks.? So the proper way
to construct a UI component in the background is:

- Construct large graph on a background thread, but do not connect to
any external/global properties yet; take as much time as you need, the
rest of the UI will keep responding and animating
- Then after the heavy work is done, connect to any external properties
on the FX thread
- When the UI has served its purpose, don't forget to disconnect from
any external properties

This can be largely transparent by using the "when" construct; using
this construct you can make links with the?external properties
immediately even on the background thread.? With the proper
when-condition, the actual listeners are added just-in-time, and on the
correct thread (typically, you'd use a condition that tracks whether the
control is part of an active scene graph, like
node->scene->window->isShowing).

--John

> ?
>
> So my recommendation would remain the same: please don't.? Always
> access JavaFX objects from the Application Thread.
>
> ?
>
> -andy
>
> ?
>
> ?
>
> ?
>
> ?
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Wednesday, April 23, 2025 at 11:41
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: ExpressionHelper thread-safety
>
> This came up most recently in the discussion of
> https://github.com/openjdk/jfx/pull/1697
>
> As noted by you and in that PR, properties are not thread-safe. If two
> threads add a listener concurrently, or if one thread adds a listener
> while and another thread notifies the listeners, it is likely to fail.
>
> So the question is: Is it worth doing something about this? And if so,
> how far do we go?
>
> Making the add/remove listeners operations on ExpressionHelper (and
> related classes?) thread-safe so that listeners could be added or
> removed on any thread concurrently with each other and with the
> operation off firing a listener probably wouldn't be too hard or have
> much downside (the performance impact should be negligible and it is
> unlikely to cause a deadlock).
>
> You still wouldn't be able to modify a property on more than one thread,
> nor control the thread on which listeners are notified (they are
> notified on the thread that mutates the property), so it won't magically
> solve all your threading issues; and you still would need to deal with
> the fact that your listener can be called on a different thread than the
> one which added it.
>
> I'd like to hear from Andy, John, and others as to whether they think
> there is value in providing partial thread-safety for the add/remove
> listener methods of properties.
>
> -- Kevin
>
>
> On 4/23/2025 9:58 AM, Christopher Schnick wrote:
> > Hello,
> >
> > I encountered a rare exception where adding listeners to an observable
> > value might break when they are added concurrently. This is due to
> > ExpressionHelper not being synchronized. I thought about how to fix
> > this on my side, but it is very difficult to do. As this is not a
> > typical platform thread issue, in my opinion it should be possible to
> > add listeners to one observable value from any thread without having
> > to think about any potential synchronization issues (which I can't
> > solve other than just running everything on one thread).
> >
> > Even worse, due to the size and array being two different variables
> > and being incremented unsafely, once such a concurrent modification
> > occurs, this invalid state will persist permanently and will cause
> > exceptions on any further method call as well. The only solution is to
> > restart the application.
> >
> > This is how a stack trace looks like when this occurs:
> >
> > 21:25:38:840 - error: Index 2 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
> > length 2
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> > ??? at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> > ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> > ??? at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> > ??? at
> >
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> > ??? at
> >
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> > ??? at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> > ??? at
> >
> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
> > ??? at java.lang.Iterable.forEach(Iterable.java:75)
> > ??? at
> >
> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
> > ??? at
> > io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
> > ??? at
> > io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
> > ??? at
> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
> > ??? at java.lang.Thread.run(Thread.java:1447)
> >
> > 21:25:38:847 - error: Index 3 out of bounds for length 2
> > java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
> > length 2
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
> > ??? at
> >
> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
> > ??? at
> > javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
> > ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
> > ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
> > ??? at
> > javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
> > ??? at
> >
> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
> > ??? at
> >
> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
> > ??? at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
> > ??? at
> >
> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
> > ??? at
> >
> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
> > ??? at
> >
> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
> > ??? at
> >
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
> > ??? at
> >
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
> >
> > This full log goes up to index 50 out of bounds due to the recurring
> > nature of this exception.
> >
> > Looking at the implementation of ExpressionHelper, I don't see any
> > harm in just synchronizing the methods, at least from my perspective.
> > But I guess that is up to the developers to decide. The only real
> > solution I have as an application developer is to perform all
> > initialization on one thread or just hope that this error is rare
> > enough, both of which aren't great options. So I hope that a potential
> > synchronization of the ExpressionHelper methods can be considered.
> >
> > Best
> > Christopher Schnick
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250424/54e887ab/attachment-0001.htm>

From jdv at openjdk.org  Thu Apr 24 06:58:00 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 24 Apr 2025 06:58:00 GMT
Subject: Integrated: 8355413: Re-enable InitializeJavaFXLaunchTests on Xorg
In-Reply-To: <7Kkryes6c6232asMRr2Gpiliu4ZrhTBig1BWT2NbwUc=.0914a6c3-4ab2-4523-890d-b926b5f6e189@github.com>
References: <7Kkryes6c6232asMRr2Gpiliu4ZrhTBig1BWT2NbwUc=.0914a6c3-4ab2-4523-890d-b926b5f6e189@github.com>
Message-ID: <eC2gb7QopL3U4DN9dfF65hz906btm3odVEPDD2dgnjI=.f5dade9f-a8e4-493f-a15a-44a1f1dc5d27@github.com>

On Wed, 23 Apr 2025 15:27:23 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> As part of https://bugs.openjdk.org/browse/JDK-8353557, InitializeJavaFXLaunchTests were disabled as they were failing in Ubuntu24.04 VM and product issue https://bugs.openjdk.org/browse/JDK-8353644 was created.
> 
> But after verifying this test on actual Ubuntu 24.04 hardware it is identified that this test doesn't fail even after multiple iterations. So we need to re-enable these tests.

This pull request has now been integrated.

Changeset: c0b798b7
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c0b798b7779a5e46c742dc749f77bd1e0b5c4abe
Stats:     10 lines in 2 files changed: 0 ins; 10 del; 0 mod

8355413: Re-enable InitializeJavaFXLaunchTests on Xorg

Reviewed-by: kcr

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

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

From lkostyra at openjdk.org  Thu Apr 24 07:53:05 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 24 Apr 2025 07:53:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
Message-ID: <UYSjIcLYWuuB8vZ0Le03zuK5Ch06_vB2uR1dDTS1xpo=.2fe4854e-9909-4dc5-8ea1-11b5953d363c@github.com>

On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
>> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 9. It no longer keeps track of ge...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reenable RestoreSceneSizeTest (JDK-8353556)

I'll give this a thorough read and report back.

In the meantime, I recently was tackling [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) and i have to wonder if it got fixed in the process of your changes? It is intermittent, I managed to get it to fail locally on my VM and it seemed like a race between window manager showing the window and us wanting to move it. Judging by the list of bugs you fixed this one could maybe also make he list.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2826691355

From jvos at openjdk.org  Thu Apr 24 08:53:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 24 Apr 2025 08:53:47 GMT
Subject: RFR: 8353632: [Linux] Undefined reference to
 PlatformSupport::OBSERVED_SETTINGS with C++14 [v2]
In-Reply-To: <Bqaw_8plneDhTR3HHHIhuxnQkE0v2cPm5epXpWZvB60=.e3e3588f-1f6a-4c88-a9af-95e1b682ba36@github.com>
References: <jlakUm_s21y5is_ZN9-_GvxoISGGP06H4i4Z-H6VdJo=.faa839da-4d16-4cdc-9024-1333bb504cdd@github.com>
 <Bqaw_8plneDhTR3HHHIhuxnQkE0v2cPm5epXpWZvB60=.e3e3588f-1f6a-4c88-a9af-95e1b682ba36@github.com>
Message-ID: <mnVztq6xE13ug1rBiciQCCEqOqTXR6cex6ldCdW278o=.32998ee4-fab0-478e-a0e2-e44fbe520b60@github.com>

On Mon, 14 Apr 2025 21:04:30 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.
>
> 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

When this patch is applied, building the OpenJFX native code for gtk works fine using the OpenJDK build process (tools/compiler).

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1768#pullrequestreview-2790286649

From jpereda at openjdk.org  Thu Apr 24 09:13:55 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 24 Apr 2025 09:13:55 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <2idaRrkQMoueQYgygbBtVXNJFvFAk8tDkrMp5nzi9s4=.d98813f7-47da-476b-80a7-749e36872c2f@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>
 <2idaRrkQMoueQYgygbBtVXNJFvFAk8tDkrMp5nzi9s4=.d98813f7-47da-476b-80a7-749e36872c2f@github.com>
Message-ID: <OlgIh6UrJhy_3FJgarlsVG47-3F9PU8abJz5GZj0rFA=.9cf3a850-7406-43f7-b14d-838b067b048c@github.com>

On Tue, 8 Apr 2025 22:41:02 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> 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.

@beldenfox Do you think we should address that issue (ctrl+left click + columnReordering) in this PR? Else, do we need to do anything else to move it forward?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2057926652

From mmack at openjdk.org  Thu Apr 24 09:18:09 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 09:18:09 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
Message-ID: <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>

On Tue, 15 Apr 2025 10:56:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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

I did some testing on windows 11 and macOS 15.4 and did a full review of the code of this PR to help moving it forward. The things I noted are all pretty minor, this is in very good shape.

Things I noticed while testing:
 - Placing Labels and Buttons in the header bar and styling it works as intended.
 - When fiddling with Windows screen scaling settings, the default header bar buttons look good. I once managed to see the shape of maximize button rendered with slightly blurry top and bottom lines of the square shape. I couldn't reproduce this, unfortunately. I wonder if having pre-rendered button shapes for all allowed scaling factors would guarantee this cannot happen, or if it would even make things worse. It's not a real problem either way.
 - When placing a MenuBar in the HeaderBar, dragging the window by clicking on the menu will open the menu and drag the window away from the opened window, which looks broken, and ComboBox and TextField don't work at all. While the fix is documented well (setting HeaderBar.draggable to false for those controls), maybe this should be set by default for all `Control` `Node`s? This would need additional documentation though.
![menu_after_drag](https://github.com/user-attachments/assets/2d139059-7ca2-4c20-95ef-1d8d8fafde59)
 - On Windows, when resizing the window horizontally to small sizes, the header button symbols are drawn over any other content in the header bar's center region, which looks broken. Can the layout be made stricter to prevent this? Or always draw the background behind these symbols?
![headerbar-content-collision](https://github.com/user-attachments/assets/6c262f07-2765-456c-98fb-d052417621da)

modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 70:

> 68:             return false;
> 69:         }
> 70:         public boolean handleMenuEvent(View view, int x, int y, int xAbs,

It may be worth adding code documentation describing what is returned here

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 90:

> 88: 
> 89:         switch (type) {
> 90:             case CLOSE -> getStage().ifPresent(Stage::close);

The getStage() calls could be pulled before the switch and return out of the method if null, instead of the ifPresent closures.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java line 89:

> 87:     public TKClipboard createDragboard(boolean isDragSource);
> 88: 
> 89:     default void processOverlayCSS() {}

This seems to be almost the only place where the quantum toolkit is made aware of CSS and layout. Could the ViewSceneOverlay have been directly added to the javafx.scene.Scene instead of the toolkit scene?

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java line 87:

> 85:             boolean _direct, boolean _inertia);
> 86: 
> 87:     public boolean menuEvent(double x, double y, double xAbs, double yAbs,

since not all xyEvent methods return something, it would be good to add code docs explaining the semantics of this returned boolean value.

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 84:

> 82:      * bar area of the stage.
> 83:      * <p>
> 84:      * This is a conditional feature, to check if it is supported see {@link Platform#isSupported(ConditionalFeature)}.

When someone who's planning on adopting the new title bar feature reads this, they might ask themselves which platforms are the supported ones, and if there are plans to support missing ones. Is there any place outside the codebase where this is actually explained? Can we link to it?

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 113:

> 111:      * of the {@code Scene} to remain easily recognizable. Applications should set the scene fill to a color
> 112:      * that matches the brightness of the user interface, even if the scene fill is not visible because it
> 113:      * is obscured by other controls.

Can we add the reasoning for this? When deciding on the actual color, it would be useful to know when exactly it may be shown.

modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 117:

> 115:      * <h4>Custom header buttons</h4>
> 116:      * If more control over the header buttons is desired, applications can opt out of the default header buttons
> 117:      * by setting {@link HeaderBar#setPrefButtonHeight(Stage, double)} to zero and providing custom header buttons

Setting height to zero to disable something is unfortunately often misused without actually disabling anything. Even though implemented correctly here, I'd prefer a more semantic way of doing this, e.g. by adding a "showHeaderButtons" property.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.h line 53:

> 51:     BOOL                isDecorated;
> 52:     BOOL                isResizable;
> 53:     BOOL                isStandardButtonsVisible;

showStandardButtons? The surrounding code does not seem to follow a strict "isXyz" naming convention for bools, so we could improve grammar here.

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 617:

> 615:         // Since DefWindowProc() is not called, call the mouse menu handler directly
> 616:         HandleViewMenuEvent(GetHWND(), WM_CONTEXTMENU, (WPARAM) GetHWND(), ::GetMessagePos ());
> 617:         //::DefWindowProc(GetHWND(), msg, wParam, lParam);

Space after GetMessagePos, leftover code comment?

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

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2778375918
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2050513166
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057822368
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057811120
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057829027
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057800013
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057803486
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057806868
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057831626
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057817035

From mmack at openjdk.org  Thu Apr 24 09:18:11 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 09:18:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v45]
In-Reply-To: <-G3RlFfLfEGe3fMn4BhEVSSHmbErM9ssYVMd6da93hE=.17a4698e-6f8f-4908-9d98-d3e6d9fe0cc4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <KW-gHxcB46OHWN8eMe5ppO-oNCNZIBnJ-kZZU3CNipo=.cd8606f5-be2d-4ed9-a68f-fb725882dd6f@github.com>
 <XL1mupinSJEZe3jyiOZeOc2s1RknlBOtLV14KGYC6WM=.e39e87fd-c88d-4157-846d-9348bcb1d88b@github.com>
 <t8I0A1KQcART0fSaALGi51cUYAlgOui1eBl-M81ud08=.862703b4-4b8e-4b3c-9a7c-a13caa633781@github.com>
 <wUu2y8YZJbSb6hHXaeYWhxOIsyh0F0WezUD8VFMotlA=.70ec08bf-e621-438d-ac15-b90adaafbd0f@github.com>
 <-G3RlFfLfEGe3fMn4BhEVSSHmbErM9ssYVMd6da93hE=.17a4698e-6f8f-4908-9d98-d3e6d9fe0cc4@github.com>
Message-ID: <Xk7d5ZeX_TluTA85qp2oYOq3JwCsldtmpMRvzpmBnKo=.33873d7e-bd4d-45fa-8858-d0d80b8ba0ea@github.com>

On Sun, 23 Mar 2025 08:56:43 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> We generally use "Behavior" in the context of controls. Although not wrong, I also think another name might be better. Maybe "Controller"? Or "Manager"? Or ...
>
> After contemplating for a while, I still think that "Behavior" is the best name. Not that it matters all that much, since it isn't public API.

+1 for "Behavior", I'd say this is close enough to dealing with a Control that it's a good match.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2057820866

From arapte at openjdk.org  Thu Apr 24 11:37:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 24 Apr 2025 11:37:00 GMT
Subject: RFR: 8088343: Race condition in javafx.concurrent.Task::cancel
 [v3]
In-Reply-To: <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
Message-ID: <Uii5rQxIxmITeneSUN5JT6a3eKkHgr6C47ENocyQyR0=.c520c6cf-69ce-4afb-be47-ae2ce1862ec1@github.com>

On Wed, 16 Apr 2025 20:28:14 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.
>> 
>> 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 five additional commits since the last revision:
> 
>  - cleanup
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - 8088343

LGTM... Could observe test failure without this change.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1769#pullrequestreview-2790761370

From jdv at openjdk.org  Thu Apr 24 11:42:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 24 Apr 2025 11:42:52 GMT
Subject: Integrated: 8318985: [macos] Incorrect 3D lighting on macOS 14 and
 later
In-Reply-To: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
References: <Y0z29aQencayICVrU3f3IsJwPTnAagOFpEKMFCR6iHk=.82eb4fd1-c324-44fd-b77a-05fd12a2ea9f@github.com>
Message-ID: <oG6XtvU2zMI1e88wykxBENT2onysaPT6658XoEWo1ho=.7815b177-d2ac-4d9a-8908-fcc93af849b1@github.com>

On Wed, 23 Apr 2025 12:13:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> When no specular color is set while rendering 3D primitives, 0.0 specular power value is used by default in our shaders.
> When same specular power value is used in pow() function in shader it results in undefined behaviour as mentioned at : https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml
> 
> By default specular power value should be 32, so now the specular_none.frag file is updated to use this default value to make sure we don't see 3D lighting issues on some platforms. This change is tested with Ensemble8 and fx83dfeatures and i don't see any regressions.
> 
> Also one of our system test _PointLightIlluminationTest_ used to fail because of this issue. It passes now with this update and it is re-enabled.

This pull request has now been integrated.

Changeset: 2617ff5c
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2617ff5c891ba182581d323d8b424e4b8a6a6b63
Stats:     35 lines in 2 files changed: 2 ins; 32 del; 1 mod

8318985: [macos] Incorrect 3D lighting on macOS 14 and later

Reviewed-by: kcr, arapte

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

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

From kcr at openjdk.org  Thu Apr 24 13:08:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 13:08:06 GMT
Subject: Integrated: 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: <WX62WjD1oip6fD_1aFyZdqyb0ELDS0ueSmsCF3esueo=.e73b6599-22f1-4594-ac3e-8ced31015e8a@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.

This pull request has now been integrated.

Changeset: 22064a8d
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/22064a8de8322fedc84c15b9815bab7184bf3677
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8353632: [Linux] Undefined reference to PlatformSupport::OBSERVED_SETTINGS with C++14

Reviewed-by: mstrauss, jvos

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

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

From kcr at openjdk.org  Thu Apr 24 13:39:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 13:39:10 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
Message-ID: <tICmPtFDS4-DO6Rkf0oop38OhZB4Mqccj3-5fCZzZHk=.0108bc98-e686-4b40-b833-5975b835929d@github.com>

On Wed, 23 Apr 2025 23:26:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed gcc 14 compiler errors.
> 
> 
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
>   178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
>       | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       | |
>       | GWeakRef **
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
>   274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
> ../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
>   202 | basedecoder_close_decoder(decoder);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
> ../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
>   548 | base->frame->data,
>       | ~~~~~~~~~~~^~~~~~
>       | |
>       | uint8_t ** {aka unsigned char **}
> ../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}

The fix looks generally good, but I left a question as to why the first fix is only done on Linux.

Reviewers: @kevinrushforth @arapte

modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst_private.h line 535:

> 533: {
> 534:   GstClockEntry entry;
> 535: #if defined (GSTREAMER_LITE) && defined(LINUX)

Why is this qualified with `defined(LINUX)`? Unless the usage of this variable is different based on the platform, I would expect that the type is wrong on all platforms. Am I missing something?

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

PR Review: https://git.openjdk.org/jfx/pull/1794#pullrequestreview-2791224174
PR Comment: https://git.openjdk.org/jfx/pull/1794#issuecomment-2827659430
PR Review Comment: https://git.openjdk.org/jfx/pull/1794#discussion_r2058463594

From jdv at openjdk.org  Thu Apr 24 14:16:44 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 24 Apr 2025 14:16:44 GMT
Subject: [jfx24u] RFR: 8318985: [macos] Incorrect 3D lighting on macOS 14 and
 later
Message-ID: <If79NL12XqhMmt15GyLkVil0NNbDLmTwQaveueMZT_c=.09a79ee7-c145-4e3c-a4d6-8d32b0e2c2da@github.com>

Backport of https://bugs.openjdk.org/browse/JDK-8318985 to jfx24u.
Fix is trivial and it resolves specular power issue on OpenGL pipeline for 3D primitives.

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

Commit messages:
 - Backport 2617ff5c891ba182581d323d8b424e4b8a6a6b63

Changes: https://git.openjdk.org/jfx24u/pull/25/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=25&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318985
  Stats: 35 lines in 2 files changed: 2 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jfx24u/pull/25.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/25/head:pull/25

PR: https://git.openjdk.org/jfx24u/pull/25

From angorya at openjdk.org  Thu Apr 24 14:42:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 24 Apr 2025 14:42:03 GMT
Subject: RFR: 8088343: Race condition in javafx.concurrent.Task::cancel
 [v3]
In-Reply-To: <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
References: <KGLNqPgypdjKohTRf6B0CvSAr-qI-w8vz_qia1fIqaw=.14734aa2-260e-449e-8a19-c196a17af657@github.com>
 <2u_TAUqdRUGNKNXeorXnvcYRbCDTsD1vJQjbY4z3L8A=.b610b3e9-093a-4bf1-8de9-17a3269611ef@github.com>
Message-ID: <PPaOhIklzJIJ78FV1mP0zjW4SgNBP8JBOY91IU5yROk=.e8649321-f350-4caa-8bac-a6718f5a16c8@github.com>

On Wed, 16 Apr 2025 20:28:14 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.
>> 
>> 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 five additional commits since the last revision:
> 
>  - cleanup
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - Merge remote-tracking branch 'origin/master' into 8088343.lifecycle
>  - 8088343

Thank you Kevin and Ambarish!

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

PR Comment: https://git.openjdk.org/jfx/pull/1769#issuecomment-2827885167

From angorya at openjdk.org  Thu Apr 24 14:42:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 24 Apr 2025 14:42:07 GMT
Subject: Integrated: 8088343: Race condition in javafx.concurrent.Task::cancel
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: <MSqFInd3elNjWa0G7ukfX_NVBznMWxiLgWgxfCVCgEs=.31efb2fe-daa5-43dd-a4c9-2ba55230e9d1@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.
> 
> Added `@RepeatedTest(50)` to the tests that used to fail intermittently - this made the test failed more reliably without the fix.

This pull request has now been integrated.

Changeset: 48240dab
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/48240dab9860728ca12f96b7cbdc4dca1d7414f2
Stats:     59 lines in 2 files changed: 35 ins; 14 del; 10 mod

8088343: Race condition in javafx.concurrent.Task::cancel

Reviewed-by: kcr, arapte

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

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

From mstrauss at openjdk.org  Thu Apr 24 14:42:33 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 14:42:33 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v66]
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: <3qVGznFiJhMhvxIiIJHjAvNXtMMuf-f65MHIsv5Ix9g=.a5368080-5144-4b88-b875-6f56c720af74@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 84 commits:

 - review comments
 - Merge branch 'master' into feature/extended-window
 - documentation
 - don't show a right-click system menu in full-screen mode
 - 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
 - ... and 74 more: https://git.openjdk.org/jfx/compare/2617ff5c...394a039a

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=65
  Stats: 6525 lines in 75 files changed: 5843 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 mstrauss at openjdk.org  Thu Apr 24 14:42:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 14:42:35 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
Message-ID: <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>

On Thu, 24 Apr 2025 08:12:57 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   documentation
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java line 89:
> 
>> 87:     public TKClipboard createDragboard(boolean isDragSource);
>> 88: 
>> 89:     default void processOverlayCSS() {}
> 
> This seems to be almost the only place where the quantum toolkit is made aware of CSS and layout. Could the ViewSceneOverlay have been directly added to the javafx.scene.Scene instead of the toolkit scene?

Yes, possibly. The reason why it's done like this is because the implementation is partially lifted from the existing full-screen overlay to minimize total changes. Maybe this would be a good candidate for a future refactor?

> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 84:
> 
>> 82:      * bar area of the stage.
>> 83:      * <p>
>> 84:      * This is a conditional feature, to check if it is supported see {@link Platform#isSupported(ConditionalFeature)}.
> 
> When someone who's planning on adopting the new title bar feature reads this, they might ask themselves which platforms are the supported ones, and if there are plans to support missing ones. Is there any place outside the codebase where this is actually explained? Can we link to it?

It is actually documented in `ConditionalFeature.EXTENDED_WINDOW`.

> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 113:
> 
>> 111:      * of the {@code Scene} to remain easily recognizable. Applications should set the scene fill to a color
>> 112:      * that matches the brightness of the user interface, even if the scene fill is not visible because it
>> 113:      * is obscured by other controls.
> 
> Can we add the reasoning for this? When deciding on the actual color, it would be useful to know when exactly it may be shown.

How a scene background is shown is already described in `Scene.fill`. Note that if we get #1655, we might want to change this part of the specification such that the color scheme of the buttons adjusts to the color scheme of the scene (i.e. `Scene.Preferences.colorScheme`) and not to its background fill.

> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 117:
> 
>> 115:      * <h4>Custom header buttons</h4>
>> 116:      * If more control over the header buttons is desired, applications can opt out of the default header buttons
>> 117:      * by setting {@link HeaderBar#setPrefButtonHeight(Stage, double)} to zero and providing custom header buttons
> 
> Setting height to zero to disable something is unfortunately often misused without actually disabling anything. Even though implemented correctly here, I'd prefer a more semantic way of doing this, e.g. by adding a "showHeaderButtons" property.

I agree when it actually makes a semantic difference. For example, there's a difference between setting `Node.opacity` to zero, and setting `Node.visible` to `false`. In the first case, the node will still receive events, while in the second case it won't. But what's the semantic difference between non-existing header buttons, and header buttons with zero height?

One argument against setting `prefButtonHeight` to zero could be that it special-cases one specific value (or two, because there's also the special value `USE_DEFAULT_SIZE`). In general, the property only describes a _preferred_ height, which the toolkit is free to honor (in any way it sees fit) or to ignore entirely. However, the two special values 0 and `USE_DEFAULT_SIZE` are specified to be honored by all toolkits in all cases.

> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.h line 53:
> 
>> 51:     BOOL                isDecorated;
>> 52:     BOOL                isResizable;
>> 53:     BOOL                isStandardButtonsVisible;
> 
> showStandardButtons? The surrounding code does not seem to follow a strict "isXyz" naming convention for bools, so we could improve grammar here.

Except for `suppressWindowMoveEvent` and `suppressWindowResizeEvent`, the code does seem to follow the "isFoo" convention...

> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 617:
> 
>> 615:         // Since DefWindowProc() is not called, call the mouse menu handler directly
>> 616:         HandleViewMenuEvent(GetHWND(), WM_CONTEXTMENU, (WPARAM) GetHWND(), ::GetMessagePos ());
>> 617:         //::DefWindowProc(GetHWND(), msg, wParam, lParam);
> 
> Space after GetMessagePos, leftover code comment?

I think the comment is there to drive the point home that `DefWindowProc` is not called? It's pre-existing code that I've just moved around.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058604759
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058604353
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058604510
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058604597
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058605178
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058604780

From angorya at openjdk.org  Thu Apr 24 14:52:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 24 Apr 2025 14:52:58 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
 <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
 <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>
Message-ID: <0QnLPv3Q9ltaNhv5hsxbfumIYsnsZ1OoP88K-ZlcKyg=.fc4f9f6e-7d94-43cc-9adf-4f72b90f5cd0@github.com>

On Thu, 24 Apr 2025 00:01:52 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Then we can close this, as that's what the original code does already.

Exactly (but I like the changes you made to add/remove "more"/"less" styles, since they won't erase any styles that the application might add during construction).

Let me ask about the original problem, which I read is difficulty to implement the dark theme.  Should we make any changes to `modena.css` in this PR instead (with or without the style manipulation)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2827925531

From mmack at openjdk.org  Thu Apr 24 14:58:06 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 14:58:06 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
Message-ID: <Pi9FlFWgwr8SryQUYjj58jrrErB8aa5Ofxqi9ARV3qM=.2017e8dc-c705-4b5e-a595-ab02b6f8759c@github.com>

On Thu, 24 Apr 2025 14:36:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 113:
>> 
>>> 111:      * of the {@code Scene} to remain easily recognizable. Applications should set the scene fill to a color
>>> 112:      * that matches the brightness of the user interface, even if the scene fill is not visible because it
>>> 113:      * is obscured by other controls.
>> 
>> Can we add the reasoning for this? When deciding on the actual color, it would be useful to know when exactly it may be shown.
>
> How a scene background is shown is already described in `Scene.fill`. Note that if we get #1655, we might want to change this part of the specification such that the color scheme of the buttons adjusts to the color scheme of the scene (i.e. `Scene.Preferences.colorScheme`) and not to its background fill.

Ah, so I think I misunderstood this. Maybe change "is adjusted to" to "is adjusted to match" or "is bound to" so it's clear the fill color is used as the background, and not something else based on it. Also, add "elsewhere" after "is not visible" so it's clear the scene fill is actually shown as the button background.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058648136

From mmack at openjdk.org  Thu Apr 24 15:04:09 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 15:04:09 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
Message-ID: <mJJ9oFQPOO4T7akHThndBiMSM6YAJAO-lGBxNjoX5Sk=.754489fb-7dcd-4bd8-a5ae-b0b4a6ef5faf@github.com>

On Thu, 24 Apr 2025 14:36:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/stage/StageStyle.java line 117:
>> 
>>> 115:      * <h4>Custom header buttons</h4>
>>> 116:      * If more control over the header buttons is desired, applications can opt out of the default header buttons
>>> 117:      * by setting {@link HeaderBar#setPrefButtonHeight(Stage, double)} to zero and providing custom header buttons
>> 
>> Setting height to zero to disable something is unfortunately often misused without actually disabling anything. Even though implemented correctly here, I'd prefer a more semantic way of doing this, e.g. by adding a "showHeaderButtons" property.
>
> I agree when it actually makes a semantic difference. For example, there's a difference between setting `Node.opacity` to zero, and setting `Node.visible` to `false`. In the first case, the node will still receive events, while in the second case it won't. But what's the semantic difference between non-existing header buttons, and header buttons with zero height?
> 
> One argument against setting `prefButtonHeight` to zero could be that it special-cases one specific value (or two, because there's also the special value `USE_DEFAULT_SIZE`). In general, the property only describes a _preferred_ height, which the toolkit is free to honor (in any way it sees fit) or to ignore entirely. However, the two special values 0 and `USE_DEFAULT_SIZE` are specified to be honored by all toolkits in all cases.

Typically it's issues related to keyboard navigation that forget to handle the zero-size case. But I agree it's ok to leave it as it is because it's documented in a way that can be trusted.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058660143

From mstrauss at openjdk.org  Thu Apr 24 15:10:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 15:10:10 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <Pi9FlFWgwr8SryQUYjj58jrrErB8aa5Ofxqi9ARV3qM=.2017e8dc-c705-4b5e-a595-ab02b6f8759c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
 <Pi9FlFWgwr8SryQUYjj58jrrErB8aa5Ofxqi9ARV3qM=.2017e8dc-c705-4b5e-a595-ab02b6f8759c@github.com>
Message-ID: <TOb6FIIFklgwvB7yW0iU64-KE9ty4vE8Nxlg2dnUk4U=.35b1d706-2751-4850-8430-7f543f161c5f@github.com>

On Thu, 24 Apr 2025 14:55:34 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> How a scene background is shown is already described in `Scene.fill`. Note that if we get #1655, we might want to change this part of the specification such that the color scheme of the buttons adjusts to the color scheme of the scene (i.e. `Scene.Preferences.colorScheme`) and not to its background fill.
>
> Ah, so I think I misunderstood this. Maybe change "is adjusted to" to "is adjusted to match" or "is bound to" so it's clear the fill color is used as the background, and not something else based on it. Also, add "elsewhere" after "is not visible" so it's clear the scene fill is actually shown as the button background.

I think that's also not what it's supposed to mean. The header buttons don't use the color of the scene background directly in their styling. Instead, they use the scene background as a proxy to gauge the color scheme of the entire application (and by extension, the custom header bar), and then use this information to adjust their own styling.

In an ideal world, we would probably want to examine the area under the header buttons and find out if light-style or dark-style header buttons should be used. But that is exceedingly complicated and probably not worth the effort.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058670814

From mmack at openjdk.org  Thu Apr 24 15:10:11 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 15:10:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
Message-ID: <ymejBx9KMDzgR_1nDqKcfUetpMs85YtgigZGN0xZMwg=.ce31b132-a2ee-4203-8680-abac7f325c56@github.com>

On Thu, 24 Apr 2025 14:36:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.h line 53:
>> 
>>> 51:     BOOL                isDecorated;
>>> 52:     BOOL                isResizable;
>>> 53:     BOOL                isStandardButtonsVisible;
>> 
>> showStandardButtons? The surrounding code does not seem to follow a strict "isXyz" naming convention for bools, so we could improve grammar here.
>
> Except for `suppressWindowMoveEvent` and `suppressWindowResizeEvent`, the code does seem to follow the "isFoo" convention...

There are also the canBecomeMainWindow, hidesOnDeactivate, worksWhenModal methods below

>> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 617:
>> 
>>> 615:         // Since DefWindowProc() is not called, call the mouse menu handler directly
>>> 616:         HandleViewMenuEvent(GetHWND(), WM_CONTEXTMENU, (WPARAM) GetHWND(), ::GetMessagePos ());
>>> 617:         //::DefWindowProc(GetHWND(), msg, wParam, lParam);
>> 
>> Space after GetMessagePos, leftover code comment?
>
> I think the comment is there to drive the point home that `DefWindowProc` is not called? It's pre-existing code that I've just moved around.

I see it's the same in FullScreenWindow.cpp, so I agree to leave it as an exact copy to make refactoring easier if this is ever de-duplicated.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058670673
PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058665551

From mstrauss at openjdk.org  Thu Apr 24 15:16:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 15:16:17 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <mJJ9oFQPOO4T7akHThndBiMSM6YAJAO-lGBxNjoX5Sk=.754489fb-7dcd-4bd8-a5ae-b0b4a6ef5faf@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
 <mJJ9oFQPOO4T7akHThndBiMSM6YAJAO-lGBxNjoX5Sk=.754489fb-7dcd-4bd8-a5ae-b0b4a6ef5faf@github.com>
Message-ID: <bGYDnNQD0vwfrAD4RC5i6J7d0vHdiMzHDSBN5oxBhXY=.52506f92-9022-43cc-bccf-5d4e97d9b641@github.com>

On Thu, 24 Apr 2025 15:01:24 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> I agree when it actually makes a semantic difference. For example, there's a difference between setting `Node.opacity` to zero, and setting `Node.visible` to `false`. In the first case, the node will still receive events, while in the second case it won't. But what's the semantic difference between non-existing header buttons, and header buttons with zero height?
>> 
>> One argument against setting `prefButtonHeight` to zero could be that it special-cases one specific value (or two, because there's also the special value `USE_DEFAULT_SIZE`). In general, the property only describes a _preferred_ height, which the toolkit is free to honor (in any way it sees fit) or to ignore entirely. However, the two special values 0 and `USE_DEFAULT_SIZE` are specified to be honored by all toolkits in all cases.
>
> Typically it's issues related to keyboard navigation that forget to handle the zero-size case. But I agree it's ok to leave it as it is because it's documented in a way that can be trusted.

That's true, but in this specific case, header buttons are not focus-traversable or visible to accessibility APIs (unlike regular buttons in the scene graph).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058683097

From mmack at openjdk.org  Thu Apr 24 15:16:17 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 15:16:17 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <TOb6FIIFklgwvB7yW0iU64-KE9ty4vE8Nxlg2dnUk4U=.35b1d706-2751-4850-8430-7f543f161c5f@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
 <Pi9FlFWgwr8SryQUYjj58jrrErB8aa5Ofxqi9ARV3qM=.2017e8dc-c705-4b5e-a595-ab02b6f8759c@github.com>
 <TOb6FIIFklgwvB7yW0iU64-KE9ty4vE8Nxlg2dnUk4U=.35b1d706-2751-4850-8430-7f543f161c5f@github.com>
Message-ID: <5eset8BqiSwEqYJSnVSuFH8e5GntBjKLp_X0Kvpw2Ds=.85a92e6d-53f9-41e0-a122-cd2f3c9372e6@github.com>

On Thu, 24 Apr 2025 15:07:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Ah, so I think I misunderstood this. Maybe change "is adjusted to" to "is adjusted to match" or "is bound to" so it's clear the fill color is used as the background, and not something else based on it. Also, add "elsewhere" after "is not visible" so it's clear the scene fill is actually shown as the button background.
>
> I think that's also not what it's supposed to mean. The header buttons don't use the color of the scene background directly in their styling. Instead, they use the scene background as a proxy to gauge the color scheme of the entire application (and by extension, the custom header bar), and then use this information to adjust their own styling.
> 
> In an ideal world, we would probably want to examine the area under the header buttons and find out if light-style or dark-style header buttons should be used. But that is exceedingly complicated and probably not worth the effort.

ok, then my original understanding was correct. Maybe clarify the second sentence like this: "To ensure this works correctly, applications should set the scene fill...". I agree the current implementation is a reasonable way to handle this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058683803

From mstrauss at openjdk.org  Thu Apr 24 15:25:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 15:25:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <5eset8BqiSwEqYJSnVSuFH8e5GntBjKLp_X0Kvpw2Ds=.85a92e6d-53f9-41e0-a122-cd2f3c9372e6@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <83tIz6d-ydYPCgn6wedq565_Lur_YYv44xr9cneBn3A=.365a9472-c350-4a55-a78d-fe7f93467031@github.com>
 <Pi9FlFWgwr8SryQUYjj58jrrErB8aa5Ofxqi9ARV3qM=.2017e8dc-c705-4b5e-a595-ab02b6f8759c@github.com>
 <TOb6FIIFklgwvB7yW0iU64-KE9ty4vE8Nxlg2dnUk4U=.35b1d706-2751-4850-8430-7f543f161c5f@github.com>
 <5eset8BqiSwEqYJSnVSuFH8e5GntBjKLp_X0Kvpw2Ds=.85a92e6d-53f9-41e0-a122-cd2f3c9372e6@github.com>
Message-ID: <Uw6rQCI8tAngcXXGfk3EKwUjn8aQLHVCh2Tlqoe_2jM=.1cd342b4-759b-4419-8449-5d96521c0946@github.com>

On Thu, 24 Apr 2025 15:13:45 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> I think that's also not what it's supposed to mean. The header buttons don't use the color of the scene background directly in their styling. Instead, they use the scene background as a proxy to gauge the color scheme of the entire application (and by extension, the custom header bar), and then use this information to adjust their own styling.
>> 
>> In an ideal world, we would probably want to examine the area under the header buttons and find out if light-style or dark-style header buttons should be used. But that is exceedingly complicated and probably not worth the effort.
>
> ok, then my original understanding was correct. Maybe clarify the second sentence like this: "To ensure this works correctly, applications should set the scene fill...". I agree the current implementation is a reasonable way to handle this.

How about this?


* The color scheme of the default header buttons is automatically adjusted to remain easily recognizable
* by inspecting the {@link Scene#fillProperty() Scene.fill} property to gauge the brightness of the user
* interface. Applications should set the scene fill to a color that matches the user interface of the header
* bar area, even if the scene fill is not visible because it is obscured by other controls.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2058705791

From jdv at openjdk.org  Thu Apr 24 15:28:58 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 24 Apr 2025 15:28:58 GMT
Subject: [jfx24u] Integrated: 8318985: [macos] Incorrect 3D lighting on macOS
 14 and later
In-Reply-To: <If79NL12XqhMmt15GyLkVil0NNbDLmTwQaveueMZT_c=.09a79ee7-c145-4e3c-a4d6-8d32b0e2c2da@github.com>
References: <If79NL12XqhMmt15GyLkVil0NNbDLmTwQaveueMZT_c=.09a79ee7-c145-4e3c-a4d6-8d32b0e2c2da@github.com>
Message-ID: <oMLXmcSkGxoL_T8sFdzZp0fnv6JDLhZIbwzKl2bG-20=.46ca474c-0446-4054-bb98-0949b7e3da95@github.com>

On Thu, 24 Apr 2025 14:03:58 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Backport of https://bugs.openjdk.org/browse/JDK-8318985 to jfx24u.
> Fix is trivial and it resolves specular power issue on OpenGL pipeline for 3D primitives.

This pull request has now been integrated.

Changeset: 61b62810
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/61b628107381cdda72238c871407be3422f31760
Stats:     35 lines in 2 files changed: 2 ins; 32 del; 1 mod

8318985: [macos] Incorrect 3D lighting on macOS 14 and later

Backport-of: 2617ff5c891ba182581d323d8b424e4b8a6a6b63

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

PR: https://git.openjdk.org/jfx24u/pull/25

From kcr at openjdk.org  Thu Apr 24 16:58:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 16:58:57 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
Message-ID: <dWWdm42_W2BakDJ1psKgrHweCi4ORNejV2j5yu_H-dU=.21758034-390c-4709-aed2-a8f8749d3884@github.com>

On Wed, 16 Apr 2025 21:17:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
>> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
>> 
>> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8169285: SWT tests should run with IS_FULL_TEST

I confirm that this runs fine on my Windows 11 system.

@Maran23 what platforms did you test this on? Windows?

I fired off a CI headful test run, and I see the following failure on Ubuntu 22.04:


> Task :swt:test FAILED

SWTCursorsTest > testImageCursor() FAILED
    org.opentest4j.AssertionFailedError: expected: not <null>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertNotNull.failNull(AssertNotNull.java:49)
        at app//org.junit.jupiter.api.AssertNotNull.assertNotNull(AssertNotNull.java:35)
        at app//org.junit.jupiter.api.AssertNotNull.assertNotNull(AssertNotNull.java:30)
        at app//org.junit.jupiter.api.Assertions.assertNotNull(Assertions.java:304)
        at app//test.javafx.embed.swt.SWTCursorsTest.lambda$testImageCursor$0(SWTCursorsTest.java:65)
        at app//org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
        at app//org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
        at app//org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5039)
        at app//org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4519)
        at app//test.javafx.embed.swt.SWTCursorsTest.lambda$testImageCursor$1(SWTCursorsTest.java:71)
        at app//test.javafx.embed.swt.SWTTest.lambda$runOnSwtThread$0(SWTTest.java:52)
        at app//org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
        at app//org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
        at app//org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5039)
        at app//org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4519)
        at app//test.javafx.embed.swt.SWTTest.runOnSwtThread(SWTTest.java:62)
        at app//test.javafx.embed.swt.SWTCursorsTest.testImageCursor(SWTCursorsTest.java:50)

3 tests completed, 1 failed


I recommend two things:

1. File a bug to track the `testImageCursor` test failure on Linux and then skip it using an `assumeTrue` (with the new bugID added as a comment).
2. Either remove the `SWT_TEST` flag, since it is always true and doesn't do anything useful, or leave it in place, change its default to "false" on macOS ("true" otherwise), and remove the check for macOS in the `test {}` block. We don't need two different ways to skip the tests on macOS.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2828275978

From mfox at openjdk.org  Thu Apr 24 17:06:59 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 24 Apr 2025 17:06:59 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
Message-ID: <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>

On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
>> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 9. It no longer keeps track of ge...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reenable RestoreSceneSizeTest (JDK-8353556)

I did a rough pass on macOS and Windows. There's some failures in the StageLocation and StageAttributes tests that I haven't had time to look into.

You might want to consider adding a few delay constants and using them instead of the 500's you've scattered through these tests. There's the delay needed for big state changes (like entering and exiting fullscreen) and that needs to be 500 or more. Then there's the delay for waiting for a layout pulse and I'm assuming that could be significantly shorter.

There seem to be places where you compare an attribute like Stage.getWidth() against a constant using strict equality and other places where you provide a tolerance delta. I suspect you want a delta in more locations but someone else will have to chime in on that. I think this mostly affects Windows machines using fractional scaling.

There was a discussion a while back about naming conventions and I think the consensus was that new tests should not have "test" in the name (so testMinSize should be minSize or minStageSize). But I might be wrong on that and in the end it's a matter of style.

tests/system/src/test/java/test/javafx/stage/FullScreenTest.java line 123:

> 121:             mode = EnumSource.Mode.INCLUDE,
> 122:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
> 123:     void testUnFullScreenChangedSize(StageStyle stageStyle) {

According to the spec changes to the size or position of a window while it's in fullscreen mode will be ignored and applied after the window leaves fullscreen mode. That's not how it currently works on macOS or Windows 11. Actually implementing that part of the spec would be complicated and probably not worth the development cycles. I would rather remove that wording and drop the testUnFullScreenChangeSize and Position tests.

I imagine this was easy to implement back when fullscreen was implemented as a separate window. It's not clear this is useful behavior, the spec might just have captured an implementation detail and elevated it to a feature.

tests/system/src/test/java/test/javafx/stage/SizingTest.java line 136:

> 134:             mode = EnumSource.Mode.INCLUDE,
> 135:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
> 136:     void testMaximizeMaxSize(StageStyle stageStyle) {

This test assumes that maximizing a window will ignore the max size settings. That's not how it works on macOS and it would be a bear to try to implement this. I think we should remove this test.

tests/system/src/test/java/test/javafx/stage/SizingTest.java line 164:

> 162:             mode = EnumSource.Mode.INCLUDE,
> 163:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
> 164:     void testFullScreenMaxSize(StageStyle stageStyle) {

You're assuming that fullscreen mode should ignore the max size properties. That's not how Windows 11 and macOS work. On macOS the window expands to the max size and is then centered on a black screen. On Windows 11 it ends up in the upper left corner with the desktop showing beneath it. It looks weird but I don't think there's much point to changing the implementation on these two platforms.

tests/system/src/test/java/test/javafx/stage/SizingTest.java line 262:

> 260:             mode = EnumSource.Mode.INCLUDE,
> 261:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT", "UTILITY"})
> 262:     void testMinSize(StageStyle stageStyle) {

Yikes! This test uncovers a long-standing problem and is failing on macOS and Windows. In general glass will only send a resize notification if the window's size actually changes. When you set the width and height here JavaFX records the new values, sends them on to glass, and glass doesn't respond because the window size doesn't change. The property values do not get corrected to reflect the actual window size and the test fails.

(I am not a fan of the JavaFX property-based API for setting window attributes. Basically JavaFX records an attribute change as if it has already happened and THEN sends it on to glass to be acted on. This creates endless complications like this.)

tests/system/src/test/java/test/robot/javafx/stage/StageLocationTest.java line 52:

> 50:     private static final int TO_Y = 500;
> 51:     private static final Color COLOR = Color.RED;
> 52:     private static final double TOLERANCE = 0.00;

You probably want a non-zero tolerance for color matching.

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-2788538337
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2056780346
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2058792439
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2058518481
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2058818935
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2058831795

From mstrauss at openjdk.org  Thu Apr 24 17:43:27 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Apr 2025 17:43:27 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
Message-ID: <_teFdUctAYYSCSdj4hzptusgzxJvfqWRrtJM167ech0=.1f91e107-1cf2-4f07-b345-7d533f43eee4@github.com>

On Thu, 24 Apr 2025 09:15:15 GMT, Markus Mack <mmack at openjdk.org> wrote:

> * When placing a MenuBar in the HeaderBar, dragging the window by clicking on the menu will open the menu and drag the window away from the opened window, which looks broken, and ComboBox and TextField don't work at all. While the fix is documented well (setting HeaderBar.draggable to false for those controls), maybe this should be set by default for all `Control` `Node`s? This would need additional documentation though.

This should not happen, as the `HeaderBar` documentation states:

The entire {@code HeaderBar} background is draggable by default, but its content is not.

Maybe you used a layout pane inside the `HeaderBar`, and set `HeaderBar.draggable = true` for the layout pane? This would then apply to the entire subtree of the pane, including the `MenuBar`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2828378638

From angorya at openjdk.org  Thu Apr 24 17:49:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 24 Apr 2025 17:49:03 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v66]
In-Reply-To: <3qVGznFiJhMhvxIiIJHjAvNXtMMuf-f65MHIsv5Ix9g=.a5368080-5144-4b88-b875-6f56c720af74@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <3qVGznFiJhMhvxIiIJHjAvNXtMMuf-f65MHIsv5Ix9g=.a5368080-5144-4b88-b875-6f56c720af74@github.com>
Message-ID: <tQ2xHBh7JIHS2Yv9oWXO8Gc6BHIE6qWUwdN9PsLReXY=.d9a91f3a-ee2d-447d-90e9-0f145303f21f@github.com>

On Thu, 24 Apr 2025 14:42:33 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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 84 commits:
> 
>  - review comments
>  - Merge branch 'master' into feature/extended-window
>  - documentation
>  - don't show a right-click system menu in full-screen mode
>  - 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
>  - ... and 74 more: https://git.openjdk.org/jfx/compare/2617ff5c...394a039a

Michael, would it be possible to add a Menu and a ComboBox to the header bar in your stage tester tool in the monkey tester?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2828390185

From pavelturk2000 at gmail.com  Thu Apr 24 18:18:58 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 24 Apr 2025 21:18:58 +0300
Subject: What strategy would you recommend for styling large documents in
 CodeArea?
Message-ID: <bb261cf9-3130-4a16-abc3-10d18608f3ac@gmail.com>

Suppose we have a very large file (1,000,000+ lines). For example, it could be an XML file or a Java class written by a beginner programmer :).
The question is: how should we handle styling for such large files?

The simplest solution is to apply styles to all lines at once. Another option is to implement lazy styling?only styling the lines that are about to be displayed (crucially, before they are shown).

Could you please clarify if lazy styling is possible in CodeArea? If yes, which API should be used for this? Or, in such cases, is a different approach recommended?

Best regards, Pavel

From mmack at openjdk.org  Thu Apr 24 18:24:06 2025
From: mmack at openjdk.org (Markus Mack)
Date: Thu, 24 Apr 2025 18:24:06 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <_teFdUctAYYSCSdj4hzptusgzxJvfqWRrtJM167ech0=.1f91e107-1cf2-4f07-b345-7d533f43eee4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <_teFdUctAYYSCSdj4hzptusgzxJvfqWRrtJM167ech0=.1f91e107-1cf2-4f07-b345-7d533f43eee4@github.com>
Message-ID: <xhMQjRSrNeuHn5_eBn9fVu6YOn56lXq8-BpgYvWZe1w=.c8c3e0c4-0673-4fb6-99bd-65e7f8a52492@github.com>

On Thu, 24 Apr 2025 17:40:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Maybe you used a layout pane inside the `HeaderBar`, and set `HeaderBar.draggable = true` for the layout pane? This would then apply to the entire subtree of the pane, including the `MenuBar`.

Yes, the controls are in an `HBox` with `HeaderBar.draggable=true`. So this is working as documented in `HeaderBar.draggable`. I still wonder if there's something that can be done to prevent controls from being broken by becoming draggable, especially if this happens inadvertently by "inheriting" this bit from its container.

Some ideas:
1) Let every `Node` in the subtree inherit the draggable=true bit, except those that are `Control`s
2) Add code to all affected controls to make them work while being draggable
3) Prevent or ignore the draggable bit on all or all affected controls
4) Don't apply draggable=true to the sub-tree

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2828487426

From andy.goryachev at oracle.com  Thu Apr 24 18:54:32 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 24 Apr 2025 18:54:32 +0000
Subject: What strategy would you recommend for styling large documents in
 CodeArea?
In-Reply-To: <bb261cf9-3130-4a16-abc3-10d18608f3ac@gmail.com>
References: <bb261cf9-3130-4a16-abc3-10d18608f3ac@gmail.com>
Message-ID: <BYAPR10MB301399B0C40071079771388CE5852@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you for a very good question!

The short answer is yes - it is possible to implement lazy styling in CodeArea, as well as to implement styling of large documents in a reasonable fashion.

The styling is performed by the decoratorProperty of the CodeTextModel.  Note: please check out the CodeAreaDemoApp in examples, along with a somewhat na?ve implementation in JavaSyntaxDecorator.  This is a synchronous decorator, which means it will likely be unsuitable for large models.

For the large models there are a few considerations that might impact the overall design:

- is it possible to style a paragraph in isolation?
- does the model support concurrent access?
- can the syntax be determined by backtracking from an arbitrary position, or it must be (re-)started from the beginning?

One possible implementation of a SyntaxDecorator would entail having a background process which gets triggered in SyntaxDecorator::createRichParagraph(model, index).  Because we don't want to hog the UI thread, it should return an unstyled RichParagraphs at first, and at the same it needs to trigger the syntax processing thread which runs from the beginning of the model.  Whenever the syntax becomes available for the requested paragraphs, the decorator invokes the StyledTextModel::fireStyleChangeEvent (in the FX Application thread), which updates the view.  Make sure the model supports concurrent read.

Depending on the nature of the data, a number of optimizations can be made.  For example, if the data has a regular structure where one does not have to restart from the beginning each time, then a synchronous implementation might work, assuming we don't need to backtrack too much to determine the syntax.

Hope this helps.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Thursday, April 24, 2025 at 11:19
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: What strategy would you recommend for styling large documents in CodeArea?
Suppose we have a very large file (1,000,000+ lines). For example, it could be an XML file or a Java class written by a beginner programmer :).
The question is: how should we handle styling for such large files?

The simplest solution is to apply styles to all lines at once. Another option is to implement lazy styling?only styling the lines that are about to be displayed (crucially, before they are shown).

Could you please clarify if lazy styling is possible in CodeArea? If yes, which API should be used for this? Or, in such cases, is a different approach recommended?

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250424/88508eb6/attachment.htm>

From crschnick at xpipe.io  Thu Apr 24 20:07:48 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 24 Apr 2025 22:07:48 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>
Message-ID: <1baaf4de-8329-472a-b9c2-4bcbc8f760d5@xpipe.io>

Hey John,

Thanks for taking your time on going into the details here.

About our use case: We are actually not constructing UI in a background 
thread, all nodes are initialized and added to the scene on the platform 
thread. This is done because previously instantiating nodes on other 
threads was unstable for some controls. So this issue has nothing to do 
with nodes at all and is purely focused on the observable value 
listeners. When initializing our application, there are some global 
properties like the app language property that a lot of other listeners 
and bindings depend on as a lot of stuff has to be changed when the 
language changes (Not just within nodes). So in practice, we have 100+ 
listeners added to these important setting properties. These listeners 
are added from various threads as the loading is parallelized. This 
loading is to some degree done before the platform is even started.

About the listener management: Yes I'm aware that this can be tricky and 
I'm doing the best to account for all of that. The GC problem is always 
a bit tricky and has led to some issues in the past. But once you are 
familiar with it, it's manageable. We are using a somewhat custom 
implementation to create nodes, link them to properties, and control 
their lifecycle properly for GC handling for that.

About the expression helper being replaced, that is unfortunate (and 
also a bit weird from my unknowing perspective, at least I don't see the 
reason for that). If you are already reworking the listeners in general, 
then it would be nice if there was a good way to synchronize the 
expressionhelper on something that is consistent.

You mentioned that there is a case that is hard to fix where a callback 
occurs on another thread while the instances are manipulated on the 
first thread. At least for us, that shouldn't be a problem. This issue I 
reported is only about adding/removing listeners in different threads. 
So I will be following the status of your PR for updates.

Best
Christopher Schnick

On 24/04/2025 03:56, John Hendrikx wrote:
>
> Hi,
>
> I don't think adding synchronized in ExpressionHelper is going to 
> really solve your problem.? It will just move it elsewhere, but feel 
> free to let me know your exact scenario.? For now I will make some 
> assumptions.
>
> I'm assuming you are constructing UI's in a background thread, and 
> this UI requires listening to some global properties, like dark/light 
> mode, or any other configuration that must dynamically change your UI 
> that's basically global, or some global modeled state that can be 
> independently used, even without a UI.? It's certainly not an 
> unreasonable scenario in larger applications that may have a lot of 
> configuration options -- I've been there myself.? I usually call these 
> "global" models; they're not part of any specific piece of the user 
> interface.? Feel free to let me know your scenario.
>
> I'm fine with UI's being constructed on background threads; anything 
> that could potentially take more than a millisecond SHOULD be done on 
> a background thread, as otherwise animations will stutter.? However, 
> there are several gotcha's with connecting a UI with?global models 
> that expose properties that you must be aware of:
>
> ## Listener Management
>
> Any UI component that listens to?global properties must either:
>
> a) unregister itself when the UI component is removed or closed (this 
> can be very difficult to track as FX has no #dispose method that will 
> be called)
> b) use a weak listener (discouraged as this can lead to phantom call 
> backs of UI's you thought no longer existed until GC runs)
> c) only register the listener when the UI is visible, and immediately 
> unregister when it becomes invisible (this can be largely automated 
> with the "when" method of ObservableValue)
>
> Failing to do so means your UI component (including all its 
> children/parents as they refer to those) will never be garbage 
> collected as a global property is referring to it.
>
> I highly recommend using the "when" construct here.? Basically, 
> whenever you want to listen to a global property from a UI component 
> insert a "when" statement:
>
> ?????? globalProperty.when(myComponentIsVisible).subscribe( ... ) or 
> addListener( ... )
>
> Or:
>
> uiProperty.bind(globalProperty.when(myComponentIsVisible));
>
> This results in listeners being registered on the FX thread just 
> before your UI becomes visible to the user.? It also removes the 
> listeners on the FX thread as soon as the UI becomes invisible. See 
> the documentation for a good condition to use with when() for this.
>
> ## Global properties may call listeners at unexpected times!
>
> When you?registered on such a property in a background thread, realize 
> that as soon as you do, you may get a callback from the FX thread.? At 
> that point in time, your presumed single threaded code that you are 
> constructing on your isolated thread is being run by two threads.? In 
> other words, you can get a callback from a global property halfway 
> during construction while your components may be in some half 
> constructed state.? As FX controls are never safe to use concurrently 
> (and neither will your listener code be) this can cause intermittent 
> problems.
>
> All that said, let's say we do want to proceed to make listener 
> management a little bit safer and prevent ExpressionHelper from going 
> into a bad state.
>
> Your proposal to just synchronize the methods in ExpressionHelper will 
> be insufficient.? ExpressionHelper replaces itself on properties all 
> the time, meaning that having a single invalidation listener on a 
> property is a different ExpressionHelper instance then when that same 
> property has 2 invalidation listeners or say just a single change 
> listener. This is done by properties like this (from ObjectPropertyBase):
>
> @Override
>
> publicvoidaddListener(InvalidationListener listener) {
>
> helper= ExpressionHelper.addListener(helper, this, listener);
>
> }
>
> As you can see, the actual helper is getting replaced in certain cases 
> (it "morphs" from one internal type to another depending on what 
> listener?types and counts are registered). That means that the first 
> call may be dealing with Helper#1, and the second call may also be 
> dealing with Helper#1 (blocking inside ExpressionHelper on a 
> synchronized block)... but the first call returns a new Helper, 
> including the new listener. When then the second call runs that was 
> blocked, it will replace the Helper again but without knowledge of the 
> listener that was added by the first call.? This happens when going 
> from a single invalidation listener to two invalidation listeners -- 
> it's a different helper.
>
> There are two ways around that; you could synchronize at an earlier 
> level before calling ExpressionHelper, adding synchronized to the 
> above method and similar methods, in all property/bindings and read 
> only property classes (about 20 orso).? Another is to?synchronize on 
> the property itself (which is passed as "this" in the above snippet).? 
> That still requires modifying 20 classes though as the 
> "removeListener" variant does not pass "this" currently, so it would 
> need to be explicitly passed for those as well to have something to 
> synchronize on.
>
> The PR which replaces 
> ExpressionHelper?(https://github.com/openjdk/jfx/pull/1081) faces 
> similar issues, but in that PR, "this" is passed already in all cases, 
> giving it something to synchronize on.? If that PR is integrated, then 
> offering thread safe adding/removal of listeners for all observable 
> that use the new solution can be done in one central location.
>
> Perhaps it is worth doing; as Kevin mentioned, within FX itself we've 
> run into problems with registering listeners that required quite some 
> changes in many places.? A central fix may be preferable; however it 
> can't and won't be a full fix, as you still must deal with potential 
> callbacks coming in from another thread shortly after registering -- a 
> scenario that most developers will likely not be taking into account 
> while writing what they presume to be single threaded code...
>
> --John
>
>
> On 23/04/2025 18:58, Christopher Schnick wrote:
>> Hello,
>>
>> I encountered a rare exception where adding listeners to an 
>> observable value might break when they are added concurrently. This 
>> is due to ExpressionHelper not being synchronized. I thought about 
>> how to fix this on my side, but it is very difficult to do. As this 
>> is not a typical platform thread issue, in my opinion it should be 
>> possible to add listeners to one observable value from any thread 
>> without having to think about any potential synchronization issues 
>> (which I can't solve other than just running everything on one thread).
>>
>> Even worse, due to the size and array being two different variables 
>> and being incremented unsafely, once such a concurrent modification 
>> occurs, this invalid state will persist permanently and will cause 
>> exceptions on any further method call as well. The only solution is 
>> to restart the application.
>>
>> This is how a stack trace looks like when this occurs:
>>
>> 21:25:38:840 - error: Index 2 out of bounds for length 2
>> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for 
>> length 2
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>> ??? at 
>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>> ??? at 
>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>> ??? at 
>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>> ??? at 
>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>> ??? at 
>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>> ??? at 
>> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>> ??? at java.lang.Iterable.forEach(Iterable.java:75)
>> ??? at 
>> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>> ??? at 
>> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>> ??? at 
>> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>> ??? at 
>> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>> ??? at java.lang.Thread.run(Thread.java:1447)
>>
>> 21:25:38:847 - error: Index 3 out of bounds for length 2
>> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for 
>> length 2
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>> ??? at 
>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>> ??? at 
>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>> ??? at 
>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>> ??? at 
>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>> ??? at 
>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>> ??? at 
>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>> ??? at 
>> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>> ??? at 
>> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>> ??? at 
>> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>> ??? at 
>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>> ??? at 
>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>>
>> This full log goes up to index 50 out of bounds due to the recurring 
>> nature of this exception.
>>
>> Looking at the implementation of ExpressionHelper, I don't see any 
>> harm in just synchronizing the methods, at least from my perspective. 
>> But I guess that is up to the developers to decide. The only real 
>> solution I have as an application developer is to perform all 
>> initialization on one thread or just hope that this error is rare 
>> enough, both of which aren't great options. So I hope that a 
>> potential synchronization of the ExpressionHelper methods can be 
>> considered.
>>
>> Best
>> Christopher Schnick
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250424/2db5033e/attachment-0001.htm>

From almatvee at openjdk.org  Thu Apr 24 20:59:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 24 Apr 2025 20:59:54 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <tICmPtFDS4-DO6Rkf0oop38OhZB4Mqccj3-5fCZzZHk=.0108bc98-e686-4b40-b833-5975b835929d@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
 <tICmPtFDS4-DO6Rkf0oop38OhZB4Mqccj3-5fCZzZHk=.0108bc98-e686-4b40-b833-5975b835929d@github.com>
Message-ID: <0iqG_2_bPVLnNSTvMLJ5KuM0gg0W7PP_mR7QGvl5aV8=.2717f418-359d-4be8-98fa-e6105d305d0f@github.com>

On Thu, 24 Apr 2025 13:33:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> - Fixed gcc 14 compiler errors.
>> 
>> 
>> ../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
>> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
>>   178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
>>       | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>       | |
>>       | GWeakRef **
>> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
>>   274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);
>> 
>> 
>> 
>> ../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
>> ../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
>>   202 | basedecoder_close_decoder(decoder);
>> 
>> 
>> 
>> ../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
>> ../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
>>   548 | base->frame->data,
>>       | ~~~~~~~~~~~^~~~~~
>>       | |
>>       | uint8_t ** {aka unsigned char **}
>> ../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}
>
> modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst_private.h line 535:
> 
>> 533: {
>> 534:   GstClockEntry entry;
>> 535: #if defined (GSTREAMER_LITE) && defined(LINUX)
> 
> Why is this qualified with `defined(LINUX)`? Unless the usage of this variable is different based on the platform, I would expect that the type is wrong on all platforms. Am I missing something?

This is old code which was restored from GStreamer 1.20.1 and only needed on Linux to support older GLib.
See https://github.com/openjdk/jfx/pull/1290.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1794#discussion_r2059220824

From kcr at openjdk.org  Thu Apr 24 21:59:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 21:59:53 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <0iqG_2_bPVLnNSTvMLJ5KuM0gg0W7PP_mR7QGvl5aV8=.2717f418-359d-4be8-98fa-e6105d305d0f@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
 <tICmPtFDS4-DO6Rkf0oop38OhZB4Mqccj3-5fCZzZHk=.0108bc98-e686-4b40-b833-5975b835929d@github.com>
 <0iqG_2_bPVLnNSTvMLJ5KuM0gg0W7PP_mR7QGvl5aV8=.2717f418-359d-4be8-98fa-e6105d305d0f@github.com>
Message-ID: <54DgumTR2RaLbnYY7qjyAUDk-VAiv6neA83gg3Y0-WA=.454ed765-60ad-49a1-bd7e-7fe0ddf52319@github.com>

On Thu, 24 Apr 2025 20:56:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gst_private.h line 535:
>> 
>>> 533: {
>>> 534:   GstClockEntry entry;
>>> 535: #if defined (GSTREAMER_LITE) && defined(LINUX)
>> 
>> Why is this qualified with `defined(LINUX)`? Unless the usage of this variable is different based on the platform, I would expect that the type is wrong on all platforms. Am I missing something?
>
> This is old code which was restored from GStreamer 1.20.1 and only needed on Linux to support older GLib.
> See https://github.com/openjdk/jfx/pull/1290.

Thanks for the explanation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1794#discussion_r2059298064

From john.hendrikx at gmail.com  Thu Apr 24 22:14:18 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 25 Apr 2025 00:14:18 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <1baaf4de-8329-472a-b9c2-4bcbc8f760d5@xpipe.io>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>
 <1baaf4de-8329-472a-b9c2-4bcbc8f760d5@xpipe.io>
Message-ID: <ea0ec13f-4345-4842-99b5-c3b057a1fcbe@gmail.com>


On 24/04/2025 22:07, Christopher Schnick wrote:
>
> Hey John,
>
> Thanks for taking your time on going into the details here.
>
> About our use case: We are actually not constructing UI in a
> background thread, all nodes are initialized and added to the scene on
> the platform thread. This is done because previously instantiating
> nodes on other threads was unstable for some controls. So this issue
> has nothing to do with nodes at all and is purely focused on the
> observable value listeners. When initializing our application, there
> are some global properties like the app language property that a lot
> of other listeners and bindings depend on as a lot of stuff has to be
> changed when the language changes (Not just within nodes). So in
> practice, we have 100+ listeners added to these important setting
> properties. These listeners are added from various threads as the
> loading is parallelized. This loading is to some degree done before
> the platform is even started.
>

Okay, so you're adding listeners in parallel, but not changing the
property at the same time listeners are being added? In other words,
there is never a listener being added/removed while concurrently
listeners are being notified?? That should be relatively safe (if
properties were thread safe in that regard :))

For a short term solution, one thing you can do is to wrap these global
properties in a custom wrapper, delegating all methods to the original
FX class.? You then add `synchronized` to all the add/remove listener
methods.? The users of these properties won't know the difference, and
ExpressionHelper should no longer get in a bad state.

>
> About the listener management: Yes I'm aware that this can be tricky
> and I'm doing the best to account for all of that. The GC problem is
> always a bit tricky and has led to some issues in the past. But once
> you are familiar with it, it's manageable. We are using a somewhat
> custom implementation to create nodes, link them to properties, and
> control their lifecycle properly for GC handling for that.
>
> About the expression helper being replaced, that is unfortunate (and
> also a bit weird from my unknowing perspective, at least I don't see
> the reason for that). If you are already reworking the listeners in
> general, then it would be nice if there was a good way to synchronize
> the expressionhelper on something that is consistent.
>
ExpressionHelper replaces itself depending on the type and count of
listeners on the property; it's an optimization to use as little memory
as possible as most properties have 0 listeners, and the next most
common amount of listeners is 1.? For those two special cases,
ExpressionHelper is null (for 0 listeners) or it is one of the SingleXXX
instances (which take less memory than the variants that have an ArrayList).

The reworking is mostly to fix another problem, and potentially making
listener management synchronized can be done in either case.

>
> You mentioned that there is a case that is hard to fix where a
> callback occurs on another thread while the instances are manipulated
> on the first thread. At least for us, that shouldn't be a problem.
> This issue I reported is only about adding/removing listeners in
> different threads. So I will be following the status of your PR for
> updates.
>
As long as you're aware that such a fix (or the wrapper I mentioned
above) only gives partial thread safety and may confuse your own
listeners if they were recently added and immediately get notified... :)

The PR mentioned is not specifically created to solve this problem; if
the team agrees that?making listener management thread-safe is the way
forward, it will probably be a separate PR and ticket.? The work
involved however is fairly trivial and could be done before or after the
PR mentioned is integrated.

--John

>
> Best
> Christopher Schnick
>
> On 24/04/2025 03:56, John Hendrikx wrote:
>>
>> Hi,
>>
>> I don't think adding synchronized in ExpressionHelper is going to
>> really solve your problem.? It will just move it elsewhere, but feel
>> free to let me know your exact scenario.? For now I will make some
>> assumptions.
>>
>> I'm assuming you are constructing UI's in a background thread, and
>> this UI requires listening to some global properties, like dark/light
>> mode, or any other configuration that must dynamically change your UI
>> that's basically global, or some global modeled state that can be
>> independently used, even without a UI.? It's certainly not an
>> unreasonable scenario in larger applications that may have a lot of
>> configuration options -- I've been there myself.? I usually call
>> these "global" models; they're not part of any specific piece of the
>> user interface.? Feel free to let me know your scenario.
>>
>> I'm fine with UI's being constructed on background threads; anything
>> that could potentially take more than a millisecond SHOULD be done on
>> a background thread, as otherwise animations will stutter.? However,
>> there are several gotcha's with connecting a UI with?global models
>> that expose properties that you must be aware of:
>>
>> ## Listener Management
>>
>> Any UI component that listens to?global properties must either:
>>
>> a) unregister itself when the UI component is removed or closed (this
>> can be very difficult to track as FX has no #dispose method that will
>> be called)
>> b) use a weak listener (discouraged as this can lead to phantom call
>> backs of UI's you thought no longer existed until GC runs)
>> c) only register the listener when the UI is visible, and immediately
>> unregister when it becomes invisible (this can be largely automated
>> with the "when" method of ObservableValue)
>>
>> Failing to do so means your UI component (including all its
>> children/parents as they refer to those) will never be garbage
>> collected as a global property is referring to it.
>>
>> I highly recommend using the "when" construct here.? Basically,
>> whenever you want to listen to a global property from a UI component
>> insert a "when" statement:
>>
>> ?????? globalProperty.when(myComponentIsVisible).subscribe( ... ) or
>> addListener( ... )
>>
>> Or:
>>
>> ?????? uiProperty.bind(globalProperty.when(myComponentIsVisible));
>>
>> This results in listeners being registered on the FX thread just
>> before your UI becomes visible to the user.? It also removes the
>> listeners on the FX thread as soon as the UI becomes invisible.? See
>> the documentation for a good condition to use with when() for this.
>>
>> ## Global properties may call listeners at unexpected times!
>>
>> When you?registered on such a property in a background thread,
>> realize that as soon as you do, you may get a callback from the FX
>> thread.? At that point in time, your presumed single threaded code
>> that you are constructing on your isolated thread is being run by two
>> threads.? In other words, you can get a callback from a global
>> property halfway during construction while your components may be in
>> some half constructed state.? As FX controls are never safe to use
>> concurrently (and neither will your listener code be) this can cause
>> intermittent problems.
>>
>> All that said, let's say we do want to proceed to make listener
>> management a little bit safer and prevent ExpressionHelper from going
>> into a bad state.?
>>
>> Your proposal to just synchronize the methods in ExpressionHelper
>> will be insufficient.? ExpressionHelper replaces itself on properties
>> all the time, meaning that having a single invalidation listener on a
>> property is a different ExpressionHelper instance then when that same
>> property has 2 invalidation listeners or say just a single change
>> listener.? This is done by properties like this (from
>> ObjectPropertyBase):
>>
>> @Override
>>
>> publicvoidaddListener(InvalidationListener listener) {
>>
>> helper= ExpressionHelper.addListener(helper, this, listener);
>>
>> }
>>
>> As you can see, the actual helper is getting replaced in certain
>> cases (it "morphs" from one internal type to another depending on
>> what listener?types and counts are registered).? That means that the
>> first call may be dealing with Helper#1, and the second call may also
>> be dealing with Helper#1 (blocking inside ExpressionHelper on a
>> synchronized block)... but the first call returns a new Helper,
>> including the new listener.? When then the second call runs that was
>> blocked, it will replace the Helper again but without knowledge of
>> the listener that was added by the first call.? This happens when
>> going from a single invalidation listener to two invalidation
>> listeners -- it's a different helper.
>>
>> There are two ways around that; you could synchronize at an earlier
>> level before calling ExpressionHelper, adding synchronized to the
>> above method and similar methods, in all property/bindings and read
>> only property classes (about 20 orso).? Another is to?synchronize on
>> the property itself (which is passed as "this" in the above
>> snippet).? That still requires modifying 20 classes though as the
>> "removeListener" variant does not pass "this" currently, so it would
>> need to be explicitly passed for those as well to have something to
>> synchronize on.
>>
>> The PR which replaces
>> ExpressionHelper?(https://github.com/openjdk/jfx/pull/1081) faces
>> similar issues, but in that PR, "this" is passed already in all
>> cases, giving it something to synchronize on.? If that PR is
>> integrated, then offering thread safe adding/removal of listeners for
>> all observable that use the new solution can be done in one central
>> location.
>>
>> Perhaps it is worth doing; as Kevin mentioned, within FX itself we've
>> run into problems with registering listeners that required quite some
>> changes in many places.? A central fix may be preferable; however it
>> can't and won't be a full fix, as you still must deal with potential
>> callbacks coming in from another thread shortly after registering --
>> a scenario that most developers will likely not be taking into
>> account while writing what they presume to be single threaded code...
>>
>> --John
>>
>>
>> On 23/04/2025 18:58, Christopher Schnick wrote:
>>> Hello,
>>>
>>> I encountered a rare exception where adding listeners to an
>>> observable value might break when they are added concurrently. This
>>> is due to ExpressionHelper not being synchronized. I thought about
>>> how to fix this on my side, but it is very difficult to do. As this
>>> is not a typical platform thread issue, in my opinion it should be
>>> possible to add listeners to one observable value from any thread
>>> without having to think about any potential synchronization issues
>>> (which I can't solve other than just running everything on one thread).
>>>
>>> Even worse, due to the size and array being two different variables
>>> and being incremented unsafely, once such a concurrent modification
>>> occurs, this invalid state will persist permanently and will cause
>>> exceptions on any further method call as well. The only solution is
>>> to restart the application.
>>>
>>> This is how a stack trace looks like when this occurs:
>>>
>>> 21:25:38:840 - error: Index 2 out of bounds for length 2
>>> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for
>>> length 2
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>> ??? at
>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>> ??? at
>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>> ??? at
>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>> ??? at
>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>>> ??? at java.lang.Iterable.forEach(Iterable.java:75)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>>> ??? at
>>> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>>> ??? at
>>> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>>> ??? at java.lang.Thread.run(Thread.java:1447)
>>>
>>> 21:25:38:847 - error: Index 3 out of bounds for length 2
>>> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for
>>> length 2
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>> ??? at
>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>> ??? at
>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>> ??? at
>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>> ??? at
>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>> ??? at
>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>> ??? at
>>> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>>> ??? at
>>> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>>> ??? at
>>> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>>> ??? at
>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>>> ??? at
>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>>>
>>> This full log goes up to index 50 out of bounds due to the recurring
>>> nature of this exception.
>>>
>>> Looking at the implementation of ExpressionHelper, I don't see any
>>> harm in just synchronizing the methods, at least from my
>>> perspective. But I guess that is up to the developers to decide. The
>>> only real solution I have as an application developer is to perform
>>> all initialization on one thread or just hope that this error is
>>> rare enough, both of which aren't great options. So I hope that a
>>> potential synchronization of the ExpressionHelper methods can be
>>> considered.
>>>
>>> Best
>>> Christopher Schnick
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250425/95ecfbe7/attachment-0001.htm>

From kcr at openjdk.org  Thu Apr 24 22:15:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 22:15:55 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
Message-ID: <4KioOZH7fyw_OugqIkQFnj_PzxuKQlra5GLEWa3WKJA=.34839996-0b3d-48ae-98ef-b985c1a02e95@github.com>

On Wed, 23 Apr 2025 23:26:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed gcc 14 compiler errors.
> 
> 
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
>   178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
>       | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       | |
>       | GWeakRef **
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
>   274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
> ../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
>   202 | basedecoder_close_decoder(decoder);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
> ../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
>   548 | base->frame->data,
>       | ~~~~~~~~~~~^~~~~~
>       | |
>       | uint8_t ** {aka unsigned char **}
> ../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}

Changes look good. I can now compile using gcc14.2

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1794#pullrequestreview-2792633904

From crschnick at xpipe.io  Thu Apr 24 22:25:43 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 25 Apr 2025 00:25:43 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <ea0ec13f-4345-4842-99b5-c3b057a1fcbe@gmail.com>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>
 <1baaf4de-8329-472a-b9c2-4bcbc8f760d5@xpipe.io>
 <ea0ec13f-4345-4842-99b5-c3b057a1fcbe@gmail.com>
Message-ID: <e448fe5c-e00b-4665-a548-26d49b1dd14d@xpipe.io>

The custom wrapper solution to synchronize sounds like a good idea. I 
will experiment with that. Would it not also be a solution to add such a 
synchronized property wrapper class to JavaFX itself?

The reason for why the expression helper replaces itself makes sense. 
However, is that still a design goal of modern JavaFX to implement these 
optimizations just to make the memory footprint of instances a bit smaller?

On 25/04/2025 00:14, John Hendrikx wrote:
>
> On 24/04/2025 22:07, Christopher Schnick wrote:
>>
>> Hey John,
>>
>> Thanks for taking your time on going into the details here.
>>
>> About our use case: We are actually not constructing UI in a 
>> background thread, all nodes are initialized and added to the scene 
>> on the platform thread. This is done because previously instantiating 
>> nodes on other threads was unstable for some controls. So this issue 
>> has nothing to do with nodes at all and is purely focused on the 
>> observable value listeners. When initializing our application, there 
>> are some global properties like the app language property that a lot 
>> of other listeners and bindings depend on as a lot of stuff has to be 
>> changed when the language changes (Not just within nodes). So in 
>> practice, we have 100+ listeners added to these important setting 
>> properties. These listeners are added from various threads as the 
>> loading is parallelized. This loading is to some degree done before 
>> the platform is even started.
>>
>
> Okay, so you're adding listeners in parallel, but not changing the 
> property at the same time listeners are being added? In other words, 
> there is never a listener being added/removed while concurrently 
> listeners are being notified?? That should be relatively safe (if 
> properties were thread safe in that regard :))
>
> For a short term solution, one thing you can do is to wrap these 
> global properties in a custom wrapper, delegating all methods to the 
> original FX class.? You then add `synchronized` to all the add/remove 
> listener methods.? The users of these properties won't know the 
> difference, and ExpressionHelper should no longer get in a bad state.
>
>>
>> About the listener management: Yes I'm aware that this can be tricky 
>> and I'm doing the best to account for all of that. The GC problem is 
>> always a bit tricky and has led to some issues in the past. But once 
>> you are familiar with it, it's manageable. We are using a somewhat 
>> custom implementation to create nodes, link them to properties, and 
>> control their lifecycle properly for GC handling for that.
>>
>> About the expression helper being replaced, that is unfortunate (and 
>> also a bit weird from my unknowing perspective, at least I don't see 
>> the reason for that). If you are already reworking the listeners in 
>> general, then it would be nice if there was a good way to synchronize 
>> the expressionhelper on something that is consistent.
>>
> ExpressionHelper replaces itself depending on the type and count of 
> listeners on the property; it's an optimization to use as little 
> memory as possible as most properties have 0 listeners, and the next 
> most common amount of listeners is 1. For those two special cases, 
> ExpressionHelper is null (for 0 listeners) or it is one of the 
> SingleXXX instances (which take less memory than the variants that 
> have an ArrayList).
>
> The reworking is mostly to fix another problem, and potentially making 
> listener management synchronized can be done in either case.
>
>>
>> You mentioned that there is a case that is hard to fix where a 
>> callback occurs on another thread while the instances are manipulated 
>> on the first thread. At least for us, that shouldn't be a problem. 
>> This issue I reported is only about adding/removing listeners in 
>> different threads. So I will be following the status of your PR for 
>> updates.
>>
> As long as you're aware that such a fix (or the wrapper I mentioned 
> above) only gives partial thread safety and may confuse your own 
> listeners if they were recently added and immediately get notified... :)
>
> The PR mentioned is not specifically created to solve this problem; if 
> the team agrees that?making listener management thread-safe is the way 
> forward, it will probably be a separate PR and ticket.? The work 
> involved however is fairly trivial and could be done before or after 
> the PR mentioned is integrated.
>
> --John
>
>>
>> Best
>> Christopher Schnick
>>
>> On 24/04/2025 03:56, John Hendrikx wrote:
>>>
>>> Hi,
>>>
>>> I don't think adding synchronized in ExpressionHelper is going to 
>>> really solve your problem.? It will just move it elsewhere, but feel 
>>> free to let me know your exact scenario.? For now I will make some 
>>> assumptions.
>>>
>>> I'm assuming you are constructing UI's in a background thread, and 
>>> this UI requires listening to some global properties, like 
>>> dark/light mode, or any other configuration that must dynamically 
>>> change your UI that's basically global, or some global modeled state 
>>> that can be independently used, even without a UI.? It's certainly 
>>> not an unreasonable scenario in larger applications that may have a 
>>> lot of configuration options -- I've been there myself.? I usually 
>>> call these "global" models; they're not part of any specific piece 
>>> of the user interface.? Feel free to let me know your scenario.
>>>
>>> I'm fine with UI's being constructed on background threads; anything 
>>> that could potentially take more than a millisecond SHOULD be done 
>>> on a background thread, as otherwise animations will stutter.? 
>>> However, there are several gotcha's with connecting a UI with?global 
>>> models that expose properties that you must be aware of:
>>>
>>> ## Listener Management
>>>
>>> Any UI component that listens to?global properties must either:
>>>
>>> a) unregister itself when the UI component is removed or closed 
>>> (this can be very difficult to track as FX has no #dispose method 
>>> that will be called)
>>> b) use a weak listener (discouraged as this can lead to phantom call 
>>> backs of UI's you thought no longer existed until GC runs)
>>> c) only register the listener when the UI is visible, and 
>>> immediately unregister when it becomes invisible (this can be 
>>> largely automated with the "when" method of ObservableValue)
>>>
>>> Failing to do so means your UI component (including all its 
>>> children/parents as they refer to those) will never be garbage 
>>> collected as a global property is referring to it.
>>>
>>> I highly recommend using the "when" construct here. Basically, 
>>> whenever you want to listen to a global property from a UI component 
>>> insert a "when" statement:
>>>
>>> ?????? globalProperty.when(myComponentIsVisible).subscribe( ... ) or 
>>> addListener( ... )
>>>
>>> Or:
>>>
>>> uiProperty.bind(globalProperty.when(myComponentIsVisible));
>>>
>>> This results in listeners being registered on the FX thread just 
>>> before your UI becomes visible to the user.? It also removes the 
>>> listeners on the FX thread as soon as the UI becomes invisible.? See 
>>> the documentation for a good condition to use with when() for this.
>>>
>>> ## Global properties may call listeners at unexpected times!
>>>
>>> When you?registered on such a property in a background thread, 
>>> realize that as soon as you do, you may get a callback from the FX 
>>> thread.? At that point in time, your presumed single threaded code 
>>> that you are constructing on your isolated thread is being run by 
>>> two threads.? In other words, you can get a callback from a global 
>>> property halfway during construction while your components may be in 
>>> some half constructed state.? As FX controls are never safe to use 
>>> concurrently (and neither will your listener code be) this can cause 
>>> intermittent problems.
>>>
>>> All that said, let's say we do want to proceed to make listener 
>>> management a little bit safer and prevent ExpressionHelper from 
>>> going into a bad state.
>>>
>>> Your proposal to just synchronize the methods in ExpressionHelper 
>>> will be insufficient.? ExpressionHelper replaces itself on 
>>> properties all the time, meaning that having a single invalidation 
>>> listener on a property is a different ExpressionHelper instance then 
>>> when that same property has 2 invalidation listeners or say just a 
>>> single change listener.? This is done by properties like this (from 
>>> ObjectPropertyBase):
>>>
>>> @Override
>>>
>>> publicvoidaddListener(InvalidationListener listener) {
>>>
>>> helper= ExpressionHelper.addListener(helper, this, listener);
>>>
>>> }
>>>
>>> As you can see, the actual helper is getting replaced in certain 
>>> cases (it "morphs" from one internal type to another depending on 
>>> what listener?types and counts are registered).? That means that the 
>>> first call may be dealing with Helper#1, and the second call may 
>>> also be dealing with Helper#1 (blocking inside ExpressionHelper on a 
>>> synchronized block)... but the first call returns a new Helper, 
>>> including the new listener.? When then the second call runs that was 
>>> blocked, it will replace the Helper again but without knowledge of 
>>> the listener that was added by the first call. This happens when 
>>> going from a single invalidation listener to two invalidation 
>>> listeners -- it's a different helper.
>>>
>>> There are two ways around that; you could synchronize at an earlier 
>>> level before calling ExpressionHelper, adding synchronized to the 
>>> above method and similar methods, in all property/bindings and read 
>>> only property classes (about 20 orso).? Another is to?synchronize on 
>>> the property itself (which is passed as "this" in the above 
>>> snippet).? That still requires modifying 20 classes though as the 
>>> "removeListener" variant does not pass "this" currently, so it would 
>>> need to be explicitly passed for those as well to have something to 
>>> synchronize on.
>>>
>>> The PR which replaces 
>>> ExpressionHelper?(https://github.com/openjdk/jfx/pull/1081) faces 
>>> similar issues, but in that PR, "this" is passed already in all 
>>> cases, giving it something to synchronize on.? If that PR is 
>>> integrated, then offering thread safe adding/removal of listeners 
>>> for all observable that use the new solution can be done in one 
>>> central location.
>>>
>>> Perhaps it is worth doing; as Kevin mentioned, within FX itself 
>>> we've run into problems with registering listeners that required 
>>> quite some changes in many places.? A central fix may be preferable; 
>>> however it can't and won't be a full fix, as you still must deal 
>>> with potential callbacks coming in from another thread shortly after 
>>> registering -- a scenario that most developers will likely not be 
>>> taking into account while writing what they presume to be single 
>>> threaded code...
>>>
>>> --John
>>>
>>>
>>> On 23/04/2025 18:58, Christopher Schnick wrote:
>>>> Hello,
>>>>
>>>> I encountered a rare exception where adding listeners to an 
>>>> observable value might break when they are added concurrently. This 
>>>> is due to ExpressionHelper not being synchronized. I thought about 
>>>> how to fix this on my side, but it is very difficult to do. As this 
>>>> is not a typical platform thread issue, in my opinion it should be 
>>>> possible to add listeners to one observable value from any thread 
>>>> without having to think about any potential synchronization issues 
>>>> (which I can't solve other than just running everything on one 
>>>> thread).
>>>>
>>>> Even worse, due to the size and array being two different variables 
>>>> and being incremented unsafely, once such a concurrent modification 
>>>> occurs, this invalid state will persist permanently and will cause 
>>>> exceptions on any further method call as well. The only solution is 
>>>> to restart the application.
>>>>
>>>> This is how a stack trace looks like when this occurs:
>>>>
>>>> 21:25:38:840 - error: Index 2 out of bounds for length 2
>>>> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for 
>>>> length 2
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>>> ??? at 
>>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>>> ??? at 
>>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>>> ??? at 
>>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>>> ??? at 
>>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>>>> ??? at java.lang.Iterable.forEach(Iterable.java:75)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>>>> ??? at 
>>>> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>>>> ??? at 
>>>> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>>>> ??? at java.lang.Thread.run(Thread.java:1447)
>>>>
>>>> 21:25:38:847 - error: Index 3 out of bounds for length 2
>>>> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for 
>>>> length 2
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>>> ??? at 
>>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>>> ??? at 
>>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>>> ??? at javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>>> ??? at 
>>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>>> ??? at 
>>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>>> ??? at 
>>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>>> ??? at 
>>>> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>>>> ??? at 
>>>> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>>>> ??? at 
>>>> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>>>> ??? at 
>>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>>>> ??? at 
>>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>>>>
>>>> This full log goes up to index 50 out of bounds due to the 
>>>> recurring nature of this exception.
>>>>
>>>> Looking at the implementation of ExpressionHelper, I don't see any 
>>>> harm in just synchronizing the methods, at least from my 
>>>> perspective. But I guess that is up to the developers to decide. 
>>>> The only real solution I have as an application developer is to 
>>>> perform all initialization on one thread or just hope that this 
>>>> error is rare enough, both of which aren't great options. So I hope 
>>>> that a potential synchronization of the ExpressionHelper methods 
>>>> can be considered.
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250425/5a9df3d3/attachment-0001.htm>

From jhendrikx at openjdk.org  Thu Apr 24 22:29:50 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 24 Apr 2025 22:29:50 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <0QnLPv3Q9ltaNhv5hsxbfumIYsnsZ1OoP88K-ZlcKyg=.fc4f9f6e-7d94-43cc-9adf-4f72b90f5cd0@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
 <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
 <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>
 <0QnLPv3Q9ltaNhv5hsxbfumIYsnsZ1OoP88K-ZlcKyg=.fc4f9f6e-7d94-43cc-9adf-4f72b90f5cd0@github.com>
Message-ID: <NpbWI2FQIuWiLjNqaWxRslUbh-VMLtK_0RjU5S2JAUw=.da857aa8-6e68-496b-abd4-ae7680c1da4b@github.com>

On Thu, 24 Apr 2025 14:50:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Then we can close this, as that's what the original code does already.
> 
> Exactly (but I like the changes you made to add/remove "more"/"less" styles, since they won't erase any styles that the application might add during construction).

The details button is private and not documented, so it is hard to reach, and even if you could it would be unsupported. 

> Let me ask about the original problem, which I read is difficulty to implement the dark theme. Should we make any changes to `modena.css` in this PR instead (with or without the style manipulation)?

The only change needed is to not wipe out the hyperlink style, then it will correctly follow the Modena specified colors which can be set to support a dark theme, see here how I do that:


.root {
    -fx-accent: #165693;
    -fx-focus-color: -fx-accent;
    -fx-base: #16181c;
    -fx-background: #22252b;
    -fx-control-inner-background: derive(-fx-base, 20%);
    -fx-control-inner-background-alt: -fx-control-inner-background;

    -fx-outer-border: derive(-fx-color, 23%);
    -fx-selection-bar-non-focused: -fx-base;

    /* Lighter than -fx-background and used to provide a small highlight when
     * needed on top of -fx-background. This is never a shadow in Modena but
     * keep -fx-shadow-highlight-color name to be compatible with Caspian.
     */
    -fx-shadow-highlight-color: ladder(
        -fx-background,
        rgba(0,0,0,0.07) 0%,
        rgba(0,0,0,0.07) 20%,
        rgba(0,0,0,0.07) 70%,
        rgba(0,0,0,0.7) 90%,
        rgba(0,0,0,0.75) 100%
      );

    /* A gradient that goes from a bit lighter than -fx-color on the top to
     * a little darker at the bottom.  Typically is the third color in the
     * -fx-background-color list as a thin highlight inside the outer border.
     * Insets are typically 1.
     */
    -fx-inner-border: linear-gradient(to bottom,
                ladder(
                    -fx-color,
                    derive(-fx-color,-30%) 0%,
                    derive(-fx-color,-20%) 40%,
                    derive(-fx-color,-25%) 60%,
                    derive(-fx-color,-55%) 80%,
                    derive(-fx-color,-55%) 90%,
                    derive(-fx-color,-75%) 100%
                ),
                ladder(
                    -fx-color,
                    derive(-fx-color,-20%) 0%,
                    derive(-fx-color,-10%) 20%,
                    derive(-fx-color,-5%) 40%,
                    derive(-fx-color,2%) 60%,
                    derive(-fx-color,5%) 100%
                ));
}


This can be combined with a native API call (on Windows) to give your Window a dark title bar as well (if you want that code, let me know).

Because the style is wiped out however, I have to work-around it and copy the hyperlink styles specifically for details-button, like so:


/* copied from .hyperlink styles for each pseudo state */
.dialog-pane > .button-bar > .container > .details-button {
    -fx-text-fill: -fx-accent;
}
.dialog-pane > .button-bar > .container > .details-button:armed,
.dialog-pane > .button-bar > .container > .details-button:visited,
.dialog-pane > .button-bar > .container > .details-button:hover:armed {
    -fx-text-fill: -fx-text-background-color;
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2828995890

From tsayao at openjdk.org  Thu Apr 24 22:34:04 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 24 Apr 2025 22:34:04 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
Message-ID: <tc_TFoUuXp96YZovGgYo70ZjFX7EqUI1VXhUSkLee60=.85ea619c-7d32-4ed0-9e01-0a65cf698d14@github.com>

On Thu, 24 Apr 2025 16:05:11 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reenable RestoreSceneSizeTest (JDK-8353556)
>
> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 136:
> 
>> 134:             mode = EnumSource.Mode.INCLUDE,
>> 135:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>> 136:     void testMaximizeMaxSize(StageStyle stageStyle) {
> 
> This test assumes that maximizing a window will ignore the max size settings. That's not how it works on macOS and it would be a bear to try to implement this. I think we should remove this test.

I actually worked around by removing the constraints, maximize and restore back the constraints when unmaximized. Window does allow this. I would prefer to not allow as well and invert the test (or remove it).

> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 262:
> 
>> 260:             mode = EnumSource.Mode.INCLUDE,
>> 261:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT", "UTILITY"})
>> 262:     void testMinSize(StageStyle stageStyle) {
> 
> Yikes! This test uncovers a long-standing problem and is failing on macOS and Windows. In general glass will only send a resize notification if the window's size actually changes. When you set the width and height here JavaFX records the new values, sends them on to glass, and glass doesn't respond because the window size doesn't change. The property values do not get corrected to reflect the actual window size and the test fails.
> 
> (I am not a fan of the JavaFX property-based API for setting window attributes. Basically JavaFX records an attribute change as if it has already happened and THEN sends it on to glass to be acted on. This creates endless complications like this.)

I had to work around this. It's a little worse, because if the Stage is fullscreen and we call setWitdth, for example, JavaFX will imediatelly set the width (but the Stage is fullscreen!).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2059329764
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2059327365

From tsayao at openjdk.org  Thu Apr 24 22:39:50 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 24 Apr 2025 22:39:50 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
Message-ID: <jm-X03GgeBJwC9uHLvdSgJeHdFxtEoMmg6BtE1nLxtw=.89e5b8e5-0181-4a9c-9fca-6479e9a16eb0@github.com>

On Thu, 24 Apr 2025 13:58:05 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reenable RestoreSceneSizeTest (JDK-8353556)
>
> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 164:
> 
>> 162:             mode = EnumSource.Mode.INCLUDE,
>> 163:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>> 164:     void testFullScreenMaxSize(StageStyle stageStyle) {
> 
> You're assuming that fullscreen mode should ignore the max size properties. That's not how Windows 11 and macOS work. On macOS the window expands to the max size and is then centered on a black screen. On Windows 11 it ends up in the upper left corner with the desktop showing beneath it. It looks weird but I don't think there's much point to changing the implementation on these two platforms.

I?m going to remove this test and undo the workaround I added to support it. I initially thought this behavior was consistent with how it works on Windows, but I think I got confused ? Windows does allow a fullscreen, unresizable Stage.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2059337917

From angorya at openjdk.org  Thu Apr 24 22:40:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 24 Apr 2025 22:40:55 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <NpbWI2FQIuWiLjNqaWxRslUbh-VMLtK_0RjU5S2JAUw=.da857aa8-6e68-496b-abd4-ae7680c1da4b@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
 <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
 <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>
 <0QnLPv3Q9ltaNhv5hsxbfumIYsnsZ1OoP88K-ZlcKyg=.fc4f9f6e-7d94-43cc-9adf-4f72b90f5cd0@github.com>
 <NpbWI2FQIuWiLjNqaWxRslUbh-VMLtK_0RjU5S2JAUw=.da857aa8-6e68-496b-abd4-ae7680c1da4b@github.com>
Message-ID: <GMmcE_BHo3KRupq3mQoXFG-W4tMcmI6lwWRcf-vEehM=.0a975557-f672-4d0f-ae9c-72179b1b40b3@github.com>

On Thu, 24 Apr 2025 22:26:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> The details button is private and not documented

it is not private: the method that creates it in the DialogPane:817 is protected, so the application can override it and get a pointer to the button, set styles, etc.

`protected Node createDetailsButton()`

>  I have to work-around it and copy the hyperlink styles specifically for details-button

Adding these styles to `modena.css` seems to be a better fix.  What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2829008247
PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2829011274

From tsayao at openjdk.org  Thu Apr 24 22:45:54 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 24 Apr 2025 22:45:54 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
Message-ID: <v15yEIMhm7PNBq5QdBoEjwajc_mAjZniL0crRzWCc1o=.0ca59373-dd4e-4ae8-a977-57d5f36b857e@github.com>

On Wed, 23 Apr 2025 19:48:52 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reenable RestoreSceneSizeTest (JDK-8353556)
>
> tests/system/src/test/java/test/javafx/stage/FullScreenTest.java line 123:
> 
>> 121:             mode = EnumSource.Mode.INCLUDE,
>> 122:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>> 123:     void testUnFullScreenChangedSize(StageStyle stageStyle) {
> 
> According to the spec changes to the size or position of a window while it's in fullscreen mode will be ignored and applied after the window leaves fullscreen mode. That's not how it currently works on macOS or Windows 11. Actually implementing that part of the spec would be complicated and probably not worth the development cycles. I would rather remove that wording and drop the testUnFullScreenChangeSize and Position tests.
> 
> I imagine this was easy to implement back when fullscreen was implemented as a separate window. It's not clear this is useful behavior, the spec might just have captured an implementation detail and elevated it to a feature.

I was kind of on the fence with this one. Maybe it?s a case where the docs in Stage.java need fixing ? they do also say that width and height should reflect the unfullscreened size. But there are several tests that check the fullscreen size against the screen size, so I opted for notifying the fullscreen sizes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2059342932

From tsayao at openjdk.org  Thu Apr 24 23:01:10 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 24 Apr 2025 23:01:10 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
Message-ID: <S7SWSsZDJN-I1bCwWJRkqM4HJp3_L7fY-sdZKjHj--M=.aae6e10a-d6ab-4254-a8c4-341f97549bb2@github.com>

On Thu, 24 Apr 2025 17:04:42 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I did a rough pass on macOS and Windows. There's some failures in the StageLocation and StageAttributes tests that I haven't had time to look into.
> 
> You might want to consider adding a few delay constants and using them instead of the 500's you've scattered through these tests. There's the delay needed for big state changes (like entering and exiting fullscreen) and that needs to be 500 or more. Then there's the delay for waiting for a layout pulse and I'm assuming that could be significantly shorter.

I can do that. Do you suggest a per test class constants, or maybe in Util?

> 
> There seem to be places where you compare an attribute like Stage.getWidth() against a constant using strict equality and other places where you provide a tolerance delta. I suspect you want a delta in more locations but someone else will have to chime in on that. I think this mostly affects Windows machines using fractional scaling.
> 

I think I did use a tolerance delta for decorated windows. Since I'm not very familiar with fractional scaling, I'm wondering how much tolerance is generally recommended in these cases?

> There was a discussion a while back about naming conventions and I think the consensus was that new tests should not have "test" in the name (so testMinSize should be minSize or minStageSize). But I might be wrong on that and in the end it's a matter of style.

I did search the mailing list and did not find the consensus (I believe there is one, I just didn't find it :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2829033954

From kcr at openjdk.org  Thu Apr 24 23:49:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Apr 2025 23:49:01 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: <lHginkdj4IJ9JuVS0GY_P8KSVYCqT8tetw2oTxoniTc=.1699a229-f7b5-44a4-abbc-1cb69bdeff73@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

Will take a look tomorrow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1755#issuecomment-2829081097

From john.hendrikx at gmail.com  Fri Apr 25 01:24:40 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 25 Apr 2025 03:24:40 +0200
Subject: ExpressionHelper thread-safety
In-Reply-To: <e448fe5c-e00b-4665-a548-26d49b1dd14d@xpipe.io>
References: <f69784b1-6614-47e0-94f1-b5d94f0e46e8@xpipe.io>
 <f0c074e8-176b-4465-a239-2dfb781e361e@gmail.com>
 <1baaf4de-8329-472a-b9c2-4bcbc8f760d5@xpipe.io>
 <ea0ec13f-4345-4842-99b5-c3b057a1fcbe@gmail.com>
 <e448fe5c-e00b-4665-a548-26d49b1dd14d@xpipe.io>
Message-ID: <352a32de-8e1d-43d0-861e-31bc561c675d@gmail.com>


On 25/04/2025 00:25, Christopher Schnick wrote:
>
> The custom wrapper solution to synchronize sounds like a good idea. I
> will experiment with that. Would it not also be a solution to add such
> a synchronized property wrapper class to JavaFX itself?
>
Yeah, it definitely could be, as long as it doesn't give the wrong
impression (ie. that such a property will function correctly in all
scenario's).? You still could only make changes to such properties on
the FX thread if any controls are registered as listener, synchronized
or not.

>
> The reason for why the expression helper replaces itself makes sense.
> However, is that still a design goal of modern JavaFX to implement
> these optimizations just to make the memory footprint of instances a
> bit smaller?
>
A single Node has?I think over a hundred properties, and per property
potentially two lists to store listeners in.? A conservative estimate
(if we didn't optimize for memory here) is that this would take 5-10 kB
to store per Node.? Multiply that with possible 1000 or more nodes, and
it does start to get somewhat significant.? As most properties have no
listeners, it makes sense to delay creating a list for storing
listeners.? There are other optimizations in play as well; a lot of
properties are created only when modified or registered on (until that
time they don't need to exist); it also speeds up the FX startup time
when less things needing to be created and loaded to get going.

--John

> On 25/04/2025 00:14, John Hendrikx wrote:
>>
>> On 24/04/2025 22:07, Christopher Schnick wrote:
>>>
>>> Hey John,
>>>
>>> Thanks for taking your time on going into the details here.
>>>
>>> About our use case: We are actually not constructing UI in a
>>> background thread, all nodes are initialized and added to the scene
>>> on the platform thread. This is done because previously
>>> instantiating nodes on other threads was unstable for some controls.
>>> So this issue has nothing to do with nodes at all and is purely
>>> focused on the observable value listeners. When initializing our
>>> application, there are some global properties like the app language
>>> property that a lot of other listeners and bindings depend on as a
>>> lot of stuff has to be changed when the language changes (Not just
>>> within nodes). So in practice, we have 100+ listeners added to these
>>> important setting properties. These listeners are added from various
>>> threads as the loading is parallelized. This loading is to some
>>> degree done before the platform is even started.
>>>
>>
>> Okay, so you're adding listeners in parallel, but not changing the
>> property at the same time listeners are being added? In other words,
>> there is never a listener being added/removed while concurrently
>> listeners are being notified?? That should be relatively safe (if
>> properties were thread safe in that regard :))
>>
>> For a short term solution, one thing you can do is to wrap these
>> global properties in a custom wrapper, delegating all methods to the
>> original FX class.? You then add `synchronized` to all the add/remove
>> listener methods.? The users of these properties won't know the
>> difference, and ExpressionHelper should no longer get in a bad state.
>>
>>>
>>> About the listener management: Yes I'm aware that this can be tricky
>>> and I'm doing the best to account for all of that. The GC problem is
>>> always a bit tricky and has led to some issues in the past. But once
>>> you are familiar with it, it's manageable. We are using a somewhat
>>> custom implementation to create nodes, link them to properties, and
>>> control their lifecycle properly for GC handling for that.
>>>
>>> About the expression helper being replaced, that is unfortunate (and
>>> also a bit weird from my unknowing perspective, at least I don't see
>>> the reason for that). If you are already reworking the listeners in
>>> general, then it would be nice if there was a good way to
>>> synchronize the expressionhelper on something that is consistent.
>>>
>> ExpressionHelper replaces itself depending on the type and count of
>> listeners on the property; it's an optimization to use as little
>> memory as possible as most properties have 0 listeners, and the next
>> most common amount of listeners is 1.? For those two special cases,
>> ExpressionHelper is null (for 0 listeners) or it is one of the
>> SingleXXX instances (which take less memory than the variants that
>> have an ArrayList).
>>
>> The reworking is mostly to fix another problem, and potentially
>> making listener management synchronized can be done in either case.
>>
>>>
>>> You mentioned that there is a case that is hard to fix where a
>>> callback occurs on another thread while the instances are
>>> manipulated on the first thread. At least for us, that shouldn't be
>>> a problem. This issue I reported is only about adding/removing
>>> listeners in different threads. So I will be following the status of
>>> your PR for updates.
>>>
>> As long as you're aware that such a fix (or the wrapper I mentioned
>> above) only gives partial thread safety and may confuse your own
>> listeners if they were recently added and immediately get notified... :)
>>
>> The PR mentioned is not specifically created to solve this problem;
>> if the team agrees that?making listener management thread-safe is the
>> way forward, it will probably be a separate PR and ticket.? The work
>> involved however is fairly trivial and could be done before or after
>> the PR mentioned is integrated.
>>
>> --John
>>
>>>
>>> Best
>>> Christopher Schnick
>>>
>>> On 24/04/2025 03:56, John Hendrikx wrote:
>>>>
>>>> Hi,
>>>>
>>>> I don't think adding synchronized in ExpressionHelper is going to
>>>> really solve your problem.? It will just move it elsewhere, but
>>>> feel free to let me know your exact scenario.? For now I will make
>>>> some assumptions.
>>>>
>>>> I'm assuming you are constructing UI's in a background thread, and
>>>> this UI requires listening to some global properties, like
>>>> dark/light mode, or any other configuration that must dynamically
>>>> change your UI that's basically global, or some global modeled
>>>> state that can be independently used, even without a UI.? It's
>>>> certainly not an unreasonable scenario in larger applications that
>>>> may have a lot of configuration options -- I've been there myself.?
>>>> I usually call these "global" models; they're not part of any
>>>> specific piece of the user interface.? Feel free to let me know
>>>> your scenario.
>>>>
>>>> I'm fine with UI's being constructed on background threads;
>>>> anything that could potentially take more than a millisecond SHOULD
>>>> be done on a background thread, as otherwise animations will
>>>> stutter.? However, there are several gotcha's with connecting a UI
>>>> with?global models that expose properties that you must be aware of:
>>>>
>>>> ## Listener Management
>>>>
>>>> Any UI component that listens to?global properties must either:
>>>>
>>>> a) unregister itself when the UI component is removed or closed
>>>> (this can be very difficult to track as FX has no #dispose method
>>>> that will be called)
>>>> b) use a weak listener (discouraged as this can lead to phantom
>>>> call backs of UI's you thought no longer existed until GC runs)
>>>> c) only register the listener when the UI is visible, and
>>>> immediately unregister when it becomes invisible (this can be
>>>> largely automated with the "when" method of ObservableValue)
>>>>
>>>> Failing to do so means your UI component (including all its
>>>> children/parents as they refer to those) will never be garbage
>>>> collected as a global property is referring to it.
>>>>
>>>> I highly recommend using the "when" construct here.? Basically,
>>>> whenever you want to listen to a global property from a UI
>>>> component insert a "when" statement:
>>>>
>>>> ?????? globalProperty.when(myComponentIsVisible).subscribe( ... )
>>>> or addListener( ... )
>>>>
>>>> Or:
>>>>
>>>> ?????? uiProperty.bind(globalProperty.when(myComponentIsVisible));
>>>>
>>>> This results in listeners being registered on the FX thread just
>>>> before your UI becomes visible to the user.? It also removes the
>>>> listeners on the FX thread as soon as the UI becomes invisible.?
>>>> See the documentation for a good condition to use with when() for this.
>>>>
>>>> ## Global properties may call listeners at unexpected times!
>>>>
>>>> When you?registered on such a property in a background thread,
>>>> realize that as soon as you do, you may get a callback from the FX
>>>> thread.? At that point in time, your presumed single threaded code
>>>> that you are constructing on your isolated thread is being run by
>>>> two threads.? In other words, you can get a callback from a global
>>>> property halfway during construction while your components may be
>>>> in some half constructed state.? As FX controls are never safe to
>>>> use concurrently (and neither will your listener code be) this can
>>>> cause intermittent problems.
>>>>
>>>> All that said, let's say we do want to proceed to make listener
>>>> management a little bit safer and prevent ExpressionHelper from
>>>> going into a bad state.?
>>>>
>>>> Your proposal to just synchronize the methods in ExpressionHelper
>>>> will be insufficient.? ExpressionHelper replaces itself on
>>>> properties all the time, meaning that having a single invalidation
>>>> listener on a property is a different ExpressionHelper instance
>>>> then when that same property has 2 invalidation listeners or say
>>>> just a single change listener.? This is done by properties like
>>>> this (from ObjectPropertyBase):
>>>>
>>>> @Override
>>>>
>>>> publicvoidaddListener(InvalidationListener listener) {
>>>>
>>>> helper= ExpressionHelper.addListener(helper, this, listener);
>>>>
>>>> }
>>>>
>>>> As you can see, the actual helper is getting replaced in certain
>>>> cases (it "morphs" from one internal type to another depending on
>>>> what listener?types and counts are registered).? That means that
>>>> the first call may be dealing with Helper#1, and the second call
>>>> may also be dealing with Helper#1 (blocking inside ExpressionHelper
>>>> on a synchronized block)... but the first call returns a new
>>>> Helper, including the new listener.? When then the second call runs
>>>> that was blocked, it will replace the Helper again but without
>>>> knowledge of the listener that was added by the first call.? This
>>>> happens when going from a single invalidation listener to two
>>>> invalidation listeners -- it's a different helper.
>>>>
>>>> There are two ways around that; you could synchronize at an earlier
>>>> level before calling ExpressionHelper, adding synchronized to the
>>>> above method and similar methods, in all property/bindings and read
>>>> only property classes (about 20 orso).? Another is to?synchronize
>>>> on the property itself (which is passed as "this" in the above
>>>> snippet).? That still requires modifying 20 classes though as the
>>>> "removeListener" variant does not pass "this" currently, so it
>>>> would need to be explicitly passed for those as well to have
>>>> something to synchronize on.
>>>>
>>>> The PR which replaces
>>>> ExpressionHelper?(https://github.com/openjdk/jfx/pull/1081) faces
>>>> similar issues, but in that PR, "this" is passed already in all
>>>> cases, giving it something to synchronize on.? If that PR is
>>>> integrated, then offering thread safe adding/removal of listeners
>>>> for all observable that use the new solution can be done in one
>>>> central location.
>>>>
>>>> Perhaps it is worth doing; as Kevin mentioned, within FX itself
>>>> we've run into problems with registering listeners that required
>>>> quite some changes in many places.? A central fix may be
>>>> preferable; however it can't and won't be a full fix, as you still
>>>> must deal with potential callbacks coming in from another thread
>>>> shortly after registering -- a scenario that most developers will
>>>> likely not be taking into account while writing what they presume
>>>> to be single threaded code...
>>>>
>>>> --John
>>>>
>>>>
>>>> On 23/04/2025 18:58, Christopher Schnick wrote:
>>>>> Hello,
>>>>>
>>>>> I encountered a rare exception where adding listeners to an
>>>>> observable value might break when they are added concurrently.
>>>>> This is due to ExpressionHelper not being synchronized. I thought
>>>>> about how to fix this on my side, but it is very difficult to do.
>>>>> As this is not a typical platform thread issue, in my opinion it
>>>>> should be possible to add listeners to one observable value from
>>>>> any thread without having to think about any potential
>>>>> synchronization issues (which I can't solve other than just
>>>>> running everything on one thread).
>>>>>
>>>>> Even worse, due to the size and array being two different
>>>>> variables and being incremented unsafely, once such a concurrent
>>>>> modification occurs, this invalid state will persist permanently
>>>>> and will cause exceptions on any further method call as well. The
>>>>> only solution is to restart the application.
>>>>>
>>>>> This is how a stack trace looks like when this occurs:
>>>>>
>>>>> 21:25:38:840 - error: Index 2 out of bounds for length 2
>>>>> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
>>>>> for length 2
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>>>> ??? at
>>>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>>>> ??? at
>>>>> javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>>>> ??? at
>>>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>>>> ??? at
>>>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>>>> ??? at
>>>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreViewState.lambda$updateContent$1(StoreViewState.java:147)
>>>>> ??? at java.lang.Iterable.forEach(Iterable.java:75)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreViewState.updateContent(StoreViewState.java:147)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreViewState.init(StoreViewState.java:93)
>>>>> ??? at
>>>>> io.xpipe.app.core.mode.BaseMode.lambda$onSwitchTo$1(BaseMode.java:109)
>>>>>
>>>>> ??? at
>>>>> io.xpipe.app.util.ThreadHelper.lambda$load$0(ThreadHelper.java:78)
>>>>> ??? at java.lang.Thread.run(Thread.java:1447)
>>>>>
>>>>> 21:25:38:847 - error: Index 3 out of bounds for length 2
>>>>> java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds
>>>>> for length 2
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:248)
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper$Generic.addListener(ExpressionHelper.java:200)
>>>>> ??? at
>>>>> com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:65)
>>>>> ??? at
>>>>> javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:86)
>>>>> ??? at
>>>>> javafx.beans.binding.StringBinding.bind(StringBinding.java:114)
>>>>> ??? at javafx.beans.binding.Bindings$7.<init>(Bindings.java:428)
>>>>> ??? at
>>>>> javafx.beans.binding.Bindings.createStringBinding(Bindings.java:426)
>>>>> ??? at
>>>>> io.xpipe.app.util.StoreStateFormat.shellEnvironment(StoreStateFormat.java:24)
>>>>> ??? at
>>>>> io.xpipe.ext.proc.env.ShellEnvironmentStoreProvider.informationString(ShellEnvironmentStoreProvider.java:155)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreEntryWrapper.update(StoreEntryWrapper.java:228)
>>>>> ??? at
>>>>> io.xpipe.app.comp.store.StoreEntryWrapper.lambda$setupListeners$3(StoreEntryWrapper.java:143)
>>>>> ??? at
>>>>> io.xpipe.app.util.PlatformThread.lambda$runLaterIfNeeded$0(PlatformThread.java:318)
>>>>> ??? at
>>>>> com.sun.javafx.application.PlatformImpl.lambda$runLater$4(PlatformImpl.java:424)
>>>>> ??? at
>>>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
>>>>> ??? at
>>>>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
>>>>>
>>>>> This full log goes up to index 50 out of bounds due to the
>>>>> recurring nature of this exception.
>>>>>
>>>>> Looking at the implementation of ExpressionHelper, I don't see any
>>>>> harm in just synchronizing the methods, at least from my
>>>>> perspective. But I guess that is up to the developers to decide.
>>>>> The only real solution I have as an application developer is to
>>>>> perform all initialization on one thread or just hope that this
>>>>> error is rare enough, both of which aren't great options. So I
>>>>> hope that a potential synchronization of the ExpressionHelper
>>>>> methods can be considered.
>>>>>
>>>>> Best
>>>>> Christopher Schnick
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250425/02d44426/attachment-0001.htm>

From mstrauss at openjdk.org  Fri Apr 25 06:40:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 25 Apr 2025 06:40:44 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v67]
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: <AVxn8zXietpwgIirfkpfOP2kxPA7LFN9oz8PI6h56ms=.7b393db2-668a-4c9b-89fe-94348b474cab@github.com>

> Implementation of [`StageStyle.EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09).

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

 - add MenuBar to stage tester
 - documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/394a039a..7dc8f5f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=66
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=65-66

  Stats: 27 lines in 2 files changed: 22 ins; 0 del; 5 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  Fri Apr 25 07:36:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 25 Apr 2025 07:36:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
Message-ID: <1nc24iHhwSrgh1qNWxs_BTHAkHEPtKY2odUZKaKcMuo=.202904d5-fe23-48d9-8985-cf010a2670ac@github.com>

On Thu, 24 Apr 2025 09:15:15 GMT, Markus Mack <mmack at openjdk.org> wrote:

> * On Windows, when resizing the window horizontally to small sizes, the header button symbols are drawn over any other content in the header bar's center region, which looks broken. Can the layout be made stricter to prevent this? Or always draw the background behind these symbols?

`HeaderBar` honors the minimum sizes of its children, so we can't size it down any further. We could potentially clip the children to an area that excludes the window buttons. To do that, we'd set a default clip node via `Node.setClip()`. On the other hand, that may be best left to application developers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2829605323

From jhendrikx at openjdk.org  Fri Apr 25 08:16:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 25 Apr 2025 08:16:06 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <GMmcE_BHo3KRupq3mQoXFG-W4tMcmI6lwWRcf-vEehM=.0a975557-f672-4d0f-ae9c-72179b1b40b3@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <c64vi-lqEncG1SMAK3tNQ3aHAOnVpCmKsR0NPGwYGBE=.f239b707-8c2b-4aef-8577-51992bbac5ae@github.com>
 <8SBtoVsmX3ha6AUM0AlaPC-m95vuWSkznEftDE7sl_w=.31f0378f-d4c6-4724-8581-34793fe267b8@github.com>
 <lLJLKUxCwsyuET5J9Oc4Qtm4rsPPU0kK47Wlg5IX6Z0=.b7bd93e6-03a0-44db-a8c8-e50f1b53c43c@github.com>
 <tzNmTP492z3PlD06O5bpBJxo3qj8yuW3mgsC5FjqvsE=.58bbe2c6-357a-45ee-a1aa-63eeb5622888@github.com>
 <5gyFK9cB1iPp9U8pqp5nd9FuDLM_VtS84VGMBu9noGw=.357670c5-32d3-4abc-b262-761387bcc671@github.com>
 <0QnLPv3Q9ltaNhv5hsxbfumIYsnsZ1OoP88K-ZlcKyg=.fc4f9f6e-7d94-43cc-9adf-4f72b90f5cd0@github.com>
 <NpbWI2FQIuWiLjNqaWxRslUbh-VMLtK_0RjU5S2JAUw=.da857aa8-6e68-496b-abd4-ae7680c1da4b@github.com>
 <GMmcE_BHo3KRupq3mQoXFG-W4tMcmI6lwWRcf-vEehM=.0a975557-f672-4d0f-ae9c-72179b1b40b3@github.com>
Message-ID: <i8RqvIsP9ofXOy_ZFMODD5wEqV7BA-cIoqa6zIPt8cA=.a332e32b-5564-4528-8aef-b650367352df@github.com>

On Thu, 24 Apr 2025 22:36:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > The details button is private and not documented
> 
> it is not private: the method that creates it in the DialogPane:817 is protected, so the application can override it and get a pointer to the button, set styles, etc.
> 
> `protected Node createDetailsButton()`

Sorry, I missed that.  So its returning a `Hyperlink` that has been mangled to not be a hyperlink anymore.

> Adding these styles to modena.css seems to be a better fix. What do you think?

Unfortunately, I think we're going in circles now. I've already given my opinion on this several times and how to most correctly resolve this.

Anyone else have an opinion on how this should be resolved?

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-2829691637

From arapte at openjdk.org  Fri Apr 25 12:00:53 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 25 Apr 2025 12:00:53 GMT
Subject: RFR: 8354336: gstclock.c: compilation error: 'incompatible pointer
 type' with gcc 14
In-Reply-To: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
Message-ID: <imLxgex4Ol-qzdyFc3g1DyhI0rib4YSxQ97PUb4iCOA=.a4a35c05-9e82-468a-a409-059364551ffe@github.com>

On Wed, 23 Apr 2025 23:26:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed gcc 14 compiler errors.
> 
> 
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
>   178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
>       | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       | |
>       | GWeakRef **
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
>   274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
> ../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
>   202 | basedecoder_close_decoder(decoder);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
> ../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
>   548 | base->frame->data,
>       | ~~~~~~~~~~~^~~~~~
>       | |
>       | uint8_t ** {aka unsigned char **}
> ../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}

LGTM. Changes seem to be in accordance to the error messages.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1794#pullrequestreview-2793892104

From mfox at openjdk.org  Fri Apr 25 16:50:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 25 Apr 2025 16:50:58 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header
In-Reply-To: <OlgIh6UrJhy_3FJgarlsVG47-3F9PU8abJz5GZj0rFA=.9cf3a850-7406-43f7-b14d-838b067b048c@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>
 <2idaRrkQMoueQYgygbBtVXNJFvFAk8tDkrMp5nzi9s4=.d98813f7-47da-476b-80a7-749e36872c2f@github.com>
 <OlgIh6UrJhy_3FJgarlsVG47-3F9PU8abJz5GZj0rFA=.9cf3a850-7406-43f7-b14d-838b067b048c@github.com>
Message-ID: <UvNde_n7C1e27AoXOZLdQVQxOPiay5463TraBdjOcAk=.0e2142f9-dde6-4f35-a135-f4a923d37f88@github.com>

On Thu, 24 Apr 2025 09:11:09 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>>> 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.
>
> @beldenfox Do you think we should address that issue (ctrl+left click + columnReordering) in this PR? Else, do we need to do anything else to move it forward?

You should be good with a few tweaks. If the press event is a popup trigger don't set the columnDragLock or call columnReorderingStarted (since you might not get a release event). In the drag handler check popupTriggeredOnMousePressed and do nothing if it's set. Your released handler looks fine as-is. I think that should cover it.

By the way, in a perfect world you would have more predictable behavior. When the popup menu is shown it would grab the mouse pointer and you would never see the release event. That would allow the user to click to bring up the popup and start dragging across the menu items without having to release the mouse.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2060570967

From almatvee at openjdk.org  Fri Apr 25 18:53:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 25 Apr 2025 18:53:01 GMT
Subject: Integrated: 8354336: gstclock.c: compilation error: 'incompatible
 pointer type' with gcc 14
In-Reply-To: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
References: <HsdaPGdnbit38ttbShD5Q0dKHVGTUBYCwelkIh8Dgmk=.20499581-a7ff-44df-ac1c-a5226308a1e9@github.com>
Message-ID: <B1kjiUNLmy6LKd4nKWIxNR4GnuYkA70T6m16Zu6cZJM=.8a73221f-41a4-4b02-98f1-5821e8abf003@github.com>

On Wed, 23 Apr 2025 23:26:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed gcc 14 compiler errors.
> 
> 
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c: In function 'gst_clock_entry_new':
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:178:48: error: passing argument 1 of 'g_weak_ref_init' from incompatible pointer type [-Wincompatible-pointer-types]
>   178 | #define GST_CLOCK_ENTRY_CLOCK_WEAK_REF(entry) (&((GstClockEntryImpl *)(entry))->clock)
>       | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       | |
>       | GWeakRef **
> ../../../gstreamer-lite/gstreamer/gst/gstclock.c:274:20: note: in expansion of macro 'GST_CLOCK_ENTRY_CLOCK_WEAK_REF'
>   274 | g_weak_ref_init (GST_CLOCK_ENTRY_CLOCK_WEAK_REF (entry), clock);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_dispose':
> ../../../plugins/av/videodecoder.c:202:31: error: passing argument 1 of 'basedecoder_close_decoder' from incompatible pointer type [-Wincompatible-pointer-types]
>   202 | basedecoder_close_decoder(decoder);
> 
> 
> 
> ../../../plugins/av/videodecoder.c: In function 'videodecoder_convert_frame':
> ../../../plugins/av/videodecoder.c:548:50: error: passing argument 2 of 'decoder->sws_scale_func' from incompatible pointer type [-Wincompatible-pointer-types]
>   548 | base->frame->data,
>       | ~~~~~~~~~~~^~~~~~
>       | |
>       | uint8_t ** {aka unsigned char **}
> ../../../plugins/av/videodecoder.c:548:50: note: expected 'const uint8_t * const*' {aka 'const unsigned char * const*'} but argument is of type 'uint8_t **' {aka 'unsigned char **'}

This pull request has now been integrated.

Changeset: 3fdd2138
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3fdd21386d6db96294fcecd80afc25d09732c067
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8354336: gstclock.c: compilation error: 'incompatible pointer type' with gcc 14

Reviewed-by: kcr, arapte

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

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

From kcr at openjdk.org  Fri Apr 25 21:55:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Apr 2025 21:55:05 GMT
Subject: RFR: 8354875: Update to GCC 14.2.0 on Linux
Message-ID: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>

This PR updates the compiler on Linux to GCC 14.2.0 (from 13.2.0) to match JDK 25.

I ran a full headless and headful test run, including building media and WebKit, on the following:

* [x] Oracle Linux 8 (our production build and headless test platform)
* [x] Ubuntu 16.04
* [x] Ubuntu 22.04
* [x] Ubuntu 24.04

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

Commit messages:
 - Merge branch 'master' into 8354875-gcc-14.2
 - Update GHA gcc compiler
 - 8354875: Update to GCC 14.2.0 on Linux

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

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

From kcr at openjdk.org  Fri Apr 25 21:55:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Apr 2025 21:55:05 GMT
Subject: RFR: 8354875: Update to GCC 14.2.0 on Linux
In-Reply-To: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
References: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
Message-ID: <bRLN9osJqSFkVOt6jyyMN0ZBIjf7wwozI9YYTfIjKII=.2b409e9e-4504-4c9f-9eb2-7556b3d9b72b@github.com>

On Thu, 17 Apr 2025 18:17:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Linux to GCC 14.2.0 (from 13.2.0) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit, on the following:
> 
> * [x] Oracle Linux 8 (our production build and headless test platform)
> * [x] Ubuntu 16.04
> * [x] Ubuntu 22.04
> * [x] Ubuntu 24.04

Reviewers: @arapte @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1784#issuecomment-2831495430

From almatvee at openjdk.org  Fri Apr 25 22:06:08 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 25 Apr 2025 22:06:08 GMT
Subject: [jfx24u] RFR: 8354336: gstclock.c: compilation error: 'incompatible
 pointer type' with gcc 14
Message-ID: <eeIljj73ALOC_EDjcOsvk_9CqflnZp5u-OZS-Uc3Uss=.1e36f818-77f3-41ee-8b91-0e310ae4747f@github.com>

Clean backport of JDK-8354336.

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

Commit messages:
 - Backport 3fdd21386d6db96294fcecd80afc25d09732c067

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

PR: https://git.openjdk.org/jfx24u/pull/26

From almatvee at openjdk.org  Fri Apr 25 23:14:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 25 Apr 2025 23:14:54 GMT
Subject: [jfx24u] Integrated: 8354336: gstclock.c: compilation error:
 'incompatible pointer type' with gcc 14
In-Reply-To: <eeIljj73ALOC_EDjcOsvk_9CqflnZp5u-OZS-Uc3Uss=.1e36f818-77f3-41ee-8b91-0e310ae4747f@github.com>
References: <eeIljj73ALOC_EDjcOsvk_9CqflnZp5u-OZS-Uc3Uss=.1e36f818-77f3-41ee-8b91-0e310ae4747f@github.com>
Message-ID: <I5W6dwDNCJX-8ofARhk7cBaM-hiKGK0mKxGolLobXcA=.1c96d14d-9790-4494-aec7-6ed77607a849@github.com>

On Fri, 25 Apr 2025 22:01:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Clean backport of JDK-8354336.

This pull request has now been integrated.

Changeset: 88a5ea06
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/88a5ea0689518ccd88f505655e24ce8aad25583b
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8354336: gstclock.c: compilation error: 'incompatible pointer type' with gcc 14

Backport-of: 3fdd21386d6db96294fcecd80afc25d09732c067

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

PR: https://git.openjdk.org/jfx24u/pull/26

From jvos at openjdk.org  Sat Apr 26 07:25:35 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 26 Apr 2025 07:25:35 GMT
Subject: [jfx17u] RFR: 8355641: Change JavaFX release version to 17.0.16 in
 jfx17u
Message-ID: <FgNdz2zPArhaiQQMHHgPCABZBGEg0lO2PJelenAiJ78=.f57c4ca1-9fdd-4470-9a06-5629f21b2a37@github.com>

Start work for 17.0.16

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

Commit messages:
 - Bump version to 17.0.16

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

PR: https://git.openjdk.org/jfx17u/pull/233

From jvos at openjdk.org  Sat Apr 26 12:52:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 26 Apr 2025 12:52:07 GMT
Subject: [jfx21u] RFR: 8355642: Change JavaFX release version to 21.0.8 in
 jfx21u
Message-ID: <tD0HIAnvzo4MB0N0NJXsDPcbfLkfFVMuWfjf2HMXVFQ=.fb9deb49-1c29-4ed6-b724-3037318709b3@github.com>

Bump version to 21.0.8

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

Commit messages:
 - Bump version to 21.0.8

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

PR: https://git.openjdk.org/jfx21u/pull/96

From tsayao at openjdk.org  Sat Apr 26 13:02:40 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 13:02:40 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v6]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <33CGw0wVgg6j0DBLFXU4mMxT2vvBTujvgnHOQczXDK4=.3a2adc2d-248d-4c10-b6be-a3f7f456d8d1@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Do not allow maximize, fullscreen past max constraints (keep allowing when unresizable)
  - Improve code on gtk_window.cpp
  - Add delta for sizing (as Martin suggested)
  - Add constants for wait times (as Martin suggested)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/02b6ab30..036be1ff

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

  Stats: 414 lines in 12 files changed: 98 ins; 134 del; 182 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Sat Apr 26 13:02:42 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 13:02:42 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <tc_TFoUuXp96YZovGgYo70ZjFX7EqUI1VXhUSkLee60=.85ea619c-7d32-4ed0-9e01-0a65cf698d14@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <Ey8VRu4BcxYgK7W0mYWd6dA-ALcKuhVVNLYLyQj4LXU=.87ca108e-ae7e-4153-b3c3-ee8e99aca214@github.com>
 <tc_TFoUuXp96YZovGgYo70ZjFX7EqUI1VXhUSkLee60=.85ea619c-7d32-4ed0-9e01-0a65cf698d14@github.com>
Message-ID: <Ji2UeLcWMStN897u-tHZxdAsAKCmFJDyGFMv-yeVXqQ=.98bcd289-88f4-46ca-98c4-e8d48715090c@github.com>

On Thu, 24 Apr 2025 22:30:50 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 136:
>> 
>>> 134:             mode = EnumSource.Mode.INCLUDE,
>>> 135:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>>> 136:     void testMaximizeMaxSize(StageStyle stageStyle) {
>> 
>> This test assumes that maximizing a window will ignore the max size settings. That's not how it works on macOS and it would be a bear to try to implement this. I think we should remove this test.
>
> I actually worked around by removing the constraints, maximize and restore back the constraints when unmaximized. Window does allow this. I would prefer to not allow as well and invert the test (or remove it).

Fixed it.

>> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 164:
>> 
>>> 162:             mode = EnumSource.Mode.INCLUDE,
>>> 163:             names = {"DECORATED", "UNDECORATED", "TRANSPARENT"})
>>> 164:     void testFullScreenMaxSize(StageStyle stageStyle) {
>> 
>> You're assuming that fullscreen mode should ignore the max size properties. That's not how Windows 11 and macOS work. On macOS the window expands to the max size and is then centered on a black screen. On Windows 11 it ends up in the upper left corner with the desktop showing beneath it. It looks weird but I don't think there's much point to changing the implementation on these two platforms.
>
> I?m going to remove this test and undo the workaround I added to support it. I initially thought this behavior was consistent with how it works on Windows, but I think I got confused ? Windows does allow a fullscreen, unresizable Stage.

Fixed it. But it does bug a little different than windows, it acts like it's fullscreen, but its not.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2061298692
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2061298700

From tsayao at openjdk.org  Sat Apr 26 13:09:11 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 13:09:11 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v7]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <Da04OwUw6kyQngnboaN_R6IFPQf-AS0YPZuul_1J_tw=.54da9ec4-02d3-4caf-a2d8-94e5f8e1bae3@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Re-enable DualWindowTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/036be1ff..8ac7978a

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

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

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

From jpereda at openjdk.org  Sat Apr 26 13:20:54 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Sat, 26 Apr 2025 13:20:54 GMT
Subject: [jfx21u] RFR: 8355642: Change JavaFX release version to 21.0.8 in
 jfx21u
In-Reply-To: <tD0HIAnvzo4MB0N0NJXsDPcbfLkfFVMuWfjf2HMXVFQ=.fb9deb49-1c29-4ed6-b724-3037318709b3@github.com>
References: <tD0HIAnvzo4MB0N0NJXsDPcbfLkfFVMuWfjf2HMXVFQ=.fb9deb49-1c29-4ed6-b724-3037318709b3@github.com>
Message-ID: <MTNZ1jHCT2EB4438h5mafJnTqIsqNk9vuoLlpu5Sgh0=.10a18723-a683-471a-9496-aca270420f53@github.com>

On Sat, 26 Apr 2025 12:45:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump version to 21.0.8

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/96#pullrequestreview-2795992812

From jpereda at openjdk.org  Sat Apr 26 13:21:51 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Sat, 26 Apr 2025 13:21:51 GMT
Subject: [jfx17u] RFR: 8355641: Change JavaFX release version to 17.0.16 in
 jfx17u
In-Reply-To: <FgNdz2zPArhaiQQMHHgPCABZBGEg0lO2PJelenAiJ78=.f57c4ca1-9fdd-4470-9a06-5629f21b2a37@github.com>
References: <FgNdz2zPArhaiQQMHHgPCABZBGEg0lO2PJelenAiJ78=.f57c4ca1-9fdd-4470-9a06-5629f21b2a37@github.com>
Message-ID: <mnnldQeEpUWUX3n7Hzj6iJDb4RzFuczKXePh3kLnzTU=.213c258f-497a-4503-9954-dec556c17ab8@github.com>

On Sat, 26 Apr 2025 07:20:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Start work for 17.0.16

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/233#pullrequestreview-2795992940

From tsayao at openjdk.org  Sat Apr 26 14:56:52 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 14:56:52 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <UYSjIcLYWuuB8vZ0Le03zuK5Ch06_vB2uR1dDTS1xpo=.2fe4854e-9909-4dc5-8ea1-11b5953d363c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <UYSjIcLYWuuB8vZ0Le03zuK5Ch06_vB2uR1dDTS1xpo=.2fe4854e-9909-4dc5-8ea1-11b5953d363c@github.com>
Message-ID: <wE8Qmq3mi_1LTmsJRa2YupRDGXaySqCvYxB1g2SS2Eo=.92257f1e-a56a-47db-a937-d3b7f5fc4b7d@github.com>

On Thu, 24 Apr 2025 07:50:12 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> I'll give this a thorough read and report back.
> 
> In the meantime, I recently was tackling [JDK-8321624](https://bugs.openjdk.org/browse/JDK-8321624) and i have to wonder if it got fixed in the process of your changes? It is intermittent, I managed to get it to fail locally on my VM and it seemed like a race between window manager showing the window and us wanting to move it. Judging by the list of bugs you fixed this one could maybe also make he list.

The `DualWindow` test consistently fails without these changes on my Ubuntu 24.04 test VM, and consistently passes with the changes applied. However, on a physical machine running Ubuntu 24.04, the test passes even without the changes.

Since I changed the positioning code and it does passes the tests, it might be fixed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2832293696

From jvos at openjdk.org  Sat Apr 26 14:58:52 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 26 Apr 2025 14:58:52 GMT
Subject: [jfx17u] Integrated: 8355641: Change JavaFX release version to 17.0.16
 in jfx17u
In-Reply-To: <FgNdz2zPArhaiQQMHHgPCABZBGEg0lO2PJelenAiJ78=.f57c4ca1-9fdd-4470-9a06-5629f21b2a37@github.com>
References: <FgNdz2zPArhaiQQMHHgPCABZBGEg0lO2PJelenAiJ78=.f57c4ca1-9fdd-4470-9a06-5629f21b2a37@github.com>
Message-ID: <EWLH2lfbdeadn3CGUkLwXLrJLBCE1q-KZr1HKIP_Zeg=.c0990aed-b5c2-49ac-a494-314bc1680b9b@github.com>

On Sat, 26 Apr 2025 07:20:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Start work for 17.0.16

This pull request has now been integrated.

Changeset: 3ee40373
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/3ee40373f1099b6ffb6eba16fe34bbd16ebb90ba
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8355641: Change JavaFX release version to 17.0.16 in jfx17u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx17u/pull/233

From jvos at openjdk.org  Sat Apr 26 15:13:56 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 26 Apr 2025 15:13:56 GMT
Subject: [jfx21u] Integrated: 8355642: Change JavaFX release version to 21.0.8
 in jfx21u
In-Reply-To: <tD0HIAnvzo4MB0N0NJXsDPcbfLkfFVMuWfjf2HMXVFQ=.fb9deb49-1c29-4ed6-b724-3037318709b3@github.com>
References: <tD0HIAnvzo4MB0N0NJXsDPcbfLkfFVMuWfjf2HMXVFQ=.fb9deb49-1c29-4ed6-b724-3037318709b3@github.com>
Message-ID: <79hRlFQ308yd_SrGXYMd9QuBiVXhGYulp8rC8QY1Jkg=.54fea17f-e011-4401-b5a5-927e64565e4e@github.com>

On Sat, 26 Apr 2025 12:45:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Bump version to 21.0.8

This pull request has now been integrated.

Changeset: 838a544f
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/838a544fe8609d42e5dacea8f1aab118f8fac13c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8355642: Change JavaFX release version to 21.0.8 in jfx21u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx21u/pull/96

From tsayao at openjdk.org  Sat Apr 26 18:24:11 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 18:24:11 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v8]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <xbLwtj9d81F8Ttmjuly78TVZCIfDSanbxBVbS76exEM=.2bd6705b-2cb9-44ba-a0ec-46db2ecc17ad@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Remove unused var

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/8ac7978a..3bfdb750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=06-07

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

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

From tsayao at openjdk.org  Sat Apr 26 19:01:13 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 26 Apr 2025 19:01:13 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v9]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> 
> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
> 
> List of changes:
> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
> 9. It no longer keeps track of geometry internally, as GTK alre...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remove old comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/3bfdb750..61230d59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=07-08

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

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

From mstrauss at openjdk.org  Sat Apr 26 19:36:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 26 Apr 2025 19:36:45 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v68]
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: <BXV4G9NMrDve_T4E6lBOLQD72MZaf8InouuXXZ7jHWI=.aebd9746-d0c7-460e-ae74-e96038c01a11@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:

  add HeaderDragType

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/7dc8f5f1..d1aa6b3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=67
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=66-67

  Stats: 252 lines in 5 files changed: 226 ins; 6 del; 20 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  Sat Apr 26 19:42:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 26 Apr 2025 19:42:58 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v65]
In-Reply-To: <xhMQjRSrNeuHn5_eBn9fVu6YOn56lXq8-BpgYvWZe1w=.c8c3e0c4-0673-4fb6-99bd-65e7f8a52492@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <GvD9ZJz0Xn0RIDl7zTAw8wEZ_X0e8dFfIjVl-zNmXKg=.8a68bebe-469a-457b-9de8-5793942632e3@github.com>
 <B0ieAmGideC2mf-1VL-R74Y0vRzEUK3SDxsPHuKIqQY=.18e1190f-6069-4d99-a0bf-65b71f8375ab@github.com>
 <_teFdUctAYYSCSdj4hzptusgzxJvfqWRrtJM167ech0=.1f91e107-1cf2-4f07-b345-7d533f43eee4@github.com>
 <xhMQjRSrNeuHn5_eBn9fVu6YOn56lXq8-BpgYvWZe1w=.c8c3e0c4-0673-4fb6-99bd-65e7f8a52492@github.com>
Message-ID: <GB7PZ-LoXVhwJUCtvGksS_2UzDFN8Gu48TrY-Px4_RU=.0a775409-9e60-4407-b8ae-ada7aa5ff9a6@github.com>

On Thu, 24 Apr 2025 18:11:32 GMT, Markus Mack <mmack at openjdk.org> wrote:

> Yes, the controls are in an `HBox` with `HeaderBar.draggable=true`. So this is working as documented in `HeaderBar.draggable`. I still wonder if there's something that can be done to prevent controls from being broken by becoming draggable, especially if this happens inadvertently by "inheriting" this bit from its container.
> 
> Some ideas:
> 
> 1. Let every `Node` in the subtree inherit the draggable=true bit, except those that are `Control`s
> 2. Add code to all affected controls to make them work while being draggable
> 3. Prevent or ignore the draggable bit on all or all affected controls
> 4. Don't apply draggable=true to the sub-tree

I've decided to replace the `draggable` bool flag with a new `HeaderDragType` enum, which is one of the following values:
1. `DRAGGABLE`: Marks a single node as draggable.
2. `DRAGGABLE_SUBTREE`: Marks a node and all of its descendants as draggable.
3. `NONE`: Cancels an inherited `DRAGGABLE_SUBTREE` flag.

This should make your example easier, since you only need to mark the `HBox` as `DRAGGABLE`, without worrying about the controls.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2832558981

From mmack at openjdk.org  Sat Apr 26 20:12:58 2025
From: mmack at openjdk.org (Markus Mack)
Date: Sat, 26 Apr 2025 20:12:58 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v68]
In-Reply-To: <BXV4G9NMrDve_T4E6lBOLQD72MZaf8InouuXXZ7jHWI=.aebd9746-d0c7-460e-ae74-e96038c01a11@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <BXV4G9NMrDve_T4E6lBOLQD72MZaf8InouuXXZ7jHWI=.aebd9746-d0c7-460e-ae74-e96038c01a11@github.com>
Message-ID: <EvBYpY97Q-kxpvalz7gY3IARWi-KhGP1AwUiUQR_4MY=.789a9536-f05d-49a8-ba59-ad241caa2b39@github.com>

On Sat, 26 Apr 2025 19:36:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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:
> 
>   add HeaderDragType

Marked as reviewed by mmack (Author).

Good idea, this looks like the most flexible option without complicating things too much. I can confirm this works well in my tests. Code changes & documentation look good as well.

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

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2796407403
PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2832583610

From tsayao at openjdk.org  Sun Apr 27 10:40:52 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 27 Apr 2025 10:40:52 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v9]
In-Reply-To: <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>
Message-ID: <UsTynwio-9gna92VGDwNz0DdUWyTtBuEabW7CejKZNE=.5d83ba6c-193a-44b0-ad5c-a06c5e1dccdd@github.com>

On Sat, 26 Apr 2025 19:01:13 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. `setAlpha` and `setBackground` were removed because they no longer function correctly due to the lack of shared rendering. It's not possible to paint a background using GTK and then render custom content on top of it, unless the rendering is done by Gtk (it is not). It is possible to keep the background by painting with cairo, and make it work with software rendering, but that's a very remote scenario;
>> 7. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 8. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 9. It no longer keeps track of ge...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old comment

Please wait a little before reviewing the glass GTK part, as I may have found a way to improve it further

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2833379138

From pavelturk2000 at gmail.com  Sun Apr 27 18:27:04 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Sun, 27 Apr 2025 21:27:04 +0300
Subject: RichTextArea: how to set wavy underline using CSS?
Message-ID: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>

RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.

However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make?all styling via CSS -
I don't want to make users use different mechanisms? for styling (CSS,? code).

Fox example, RichTextFX contains the following rules:

 ??? /* the color of the underline */
 ??? -rtfx-underline-color: <paint>;

 ??? /* the radius used to create waved underline */
 ??? -rtfx-underline-wave-radius: <size>;

Could anyone say how to do it in JFX RichTextArea?

Best regards, Pavel

From kizune at openjdk.org  Mon Apr 28 04:43:34 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 28 Apr 2025 04:43:34 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
Message-ID: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>

Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

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

Commit messages:
 - 8350316: Create implementation of NSAccessibilityProgressIndicator protocol

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

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

From mstrauss at openjdk.org  Mon Apr 28 07:38:37 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 28 Apr 2025 07:38:37 GMT
Subject: RFR: 8345348: CSS media feature queries [v20]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <eiZPXS_vMqfsNVdgWDNRko6eujmeRZXYfXcOqgTXHms=.6a525033-6a23-4d8b-8b5a-8f0540ce8e21@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 28 commits:

 - Merge branch 'master' into feature/media-queries
 - reorder fields
 - remove ReadOnlyBooleanWrapper
 - Scene preferences only actively observe platform preferences when the scene is showing
 - formatting
 - typo
 - use equality instead of identity
 - rename TokenStream methods
 - improved implementation of NullCoalescingPropertyBase
 - small refactor
 - ... and 18 more: https://git.openjdk.org/jfx/compare/3fdd2138...32abb8a3

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

Changes: https://git.openjdk.org/jfx/pull/1655/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=19
  Stats: 5135 lines in 41 files changed: 3983 ins; 1050 del; 102 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 28 08:04:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 28 Apr 2025 08:04:44 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v69]
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: <cV5qjY_gwOPxzjwxGmQfvhDjk46xETlWW0q5Zl_0EXQ=.90f09339-4cf4-447d-bee0-6cdd61fcc7b7@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 89 commits:

 - Merge branch 'master' into feature/extended-window
 - doc change
 - add HeaderDragType
 - add MenuBar to stage tester
 - documentation
 - review comments
 - Merge branch 'master' into feature/extended-window
 - documentation
 - don't show a right-click system menu in full-screen mode
 - Merge branch 'master' into feature/extended-window
 - ... and 79 more: https://git.openjdk.org/jfx/compare/3fdd2138...6a2f05d6

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

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=68
  Stats: 6768 lines in 76 files changed: 6086 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  Mon Apr 28 09:38:06 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 28 Apr 2025 09:38:06 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v3]
In-Reply-To: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
Message-ID: <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>

> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
> 
> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  SWT_TEST default is false on MacOS

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1783/files
  - new: https://git.openjdk.org/jfx/pull/1783/files/a99f75ae..eabc48a2

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

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

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

From mhanl at openjdk.org  Mon Apr 28 09:38:07 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 28 Apr 2025 09:38:07 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests
In-Reply-To: <vY9RFO_WW9smy9Uc4kiP4O3zWc0bL_5lgV1LBw27r5U=.ed635cf0-2f45-4ba0-a69e-593eb30bbf32@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <vY9RFO_WW9smy9Uc4kiP4O3zWc0bL_5lgV1LBw27r5U=.ed635cf0-2f45-4ba0-a69e-593eb30bbf32@github.com>
Message-ID: <I9694a_1yL3a8WN9kqq8QnXqdxLGtM5nYsZbSmrMxAE=.a6825a52-0f8f-48dd-9aaa-0db300141011@github.com>

On Wed, 16 Apr 2025 19:00:53 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
>> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
>> 
>> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.
>
> Checking the GHA build, `IS_FULL_TEST` actually might be needed. Linux fails with `org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]` when creating the `Display`.

> @Maran23 what platforms did you test this on? Windows?

Yes, Windows 11.

> change its default to "false" on macOS ("true" otherwise)

Yes this seems like a good idea, I think it is more clean to have the definition where the property is (with the conditional for MacOS), instead of the `test{}` block, as you also suggested.

I want to check the tests on MacOS (See if I can figure out why they fail) and Linux (checkout `testImageCursor`) if time permits, but I might not be able to make it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2834610822

From jpereda at openjdk.org  Mon Apr 28 10:32:34 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 10:32:34 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
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: <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@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.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1754/files
  - new: https://git.openjdk.org/jfx/pull/1754/files/612e345a..561fcf18

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

  Stats: 37 lines in 2 files changed: 34 ins; 0 del; 3 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 jpereda at openjdk.org  Mon Apr 28 10:32:35 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 10:32:35 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
In-Reply-To: <UvNde_n7C1e27AoXOZLdQVQxOPiay5463TraBdjOcAk=.0e2142f9-dde6-4f35-a135-f4a923d37f88@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>
 <2idaRrkQMoueQYgygbBtVXNJFvFAk8tDkrMp5nzi9s4=.d98813f7-47da-476b-80a7-749e36872c2f@github.com>
 <OlgIh6UrJhy_3FJgarlsVG47-3F9PU8abJz5GZj0rFA=.9cf3a850-7406-43f7-b14d-838b067b048c@github.com>
 <UvNde_n7C1e27AoXOZLdQVQxOPiay5463TraBdjOcAk=.0e2142f9-dde6-4f35-a135-f4a923d37f88@github.com>
Message-ID: <DjmlgutJBfT3PwNcghMgsUdCRpiuYsTdVQDFrQ0Eduk=.bef1ffb4-8d41-447f-9d2f-747a22c0e593@github.com>

On Fri, 25 Apr 2025 16:48:40 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> @beldenfox Do you think we should address that issue (ctrl+left click + columnReordering) in this PR? Else, do we need to do anything else to move it forward?
>
> You should be good with a few tweaks. If the press event is a popup trigger don't set the columnDragLock or call columnReorderingStarted (since you might not get a release event). In the drag handler check popupTriggeredOnMousePressed and do nothing if it's set. Your released handler looks fine as-is. I think that should cover it.
> 
> By the way, in a perfect world you would have more predictable behavior. When the popup menu is shown it would grab the mouse pointer and you would never see the release event. That would allow the user to click to bring up the popup and start dragging across the menu items without having to release the mouse.

Thanks, @beldenfox! I've included your suggestions,  and also added the ctrl+left click macOS case to the test.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1754#discussion_r2063378261

From arapte at openjdk.org  Mon Apr 28 10:32:51 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 28 Apr 2025 10:32:51 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <T7Us2HS5nfqfpWngu34D37PTkCfVJQtCcd-64L9y9wE=.f923eb1e-bf6b-4ea1-bf62-d421e53c799e@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

A minor comment that the 4 new files require an empty line at the end. and I added another inline query.
I shall test the change and update.

modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXProgressIndicatorAccessibility.h line 30:

> 28: #import <AppKit/NSAccessibility.h>
> 29: 
> 30: @interface JFXProgressIndicatorAccessibility :

Will we use the same interface of ProgressBar? If yes, a comment here mentioning the same would be helpful.

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

PR Review: https://git.openjdk.org/jfx/pull/1796#pullrequestreview-2798834168
PR Review Comment: https://git.openjdk.org/jfx/pull/1796#discussion_r2063377739

From kcr at openjdk.org  Mon Apr 28 13:40:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 13:40:54 GMT
Subject: RFR: 8355415: RichTextArea: NPE in VFlow::scrollCaretToVisible
In-Reply-To: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
References: <6-2uIfU183KmH2QLiWhO15d2Gx3fYnTqlAS5jIeel3I=.dcc4b1ca-e2fc-4994-b0cc-580a1dc78933@github.com>
Message-ID: <kjVMdAJwletiqqUl1aqzL0fPFQGrC1vroNzll6udzV8=.95cf3f76-623e-4f39-8ab1-63f246c42cb8@github.com>

On Wed, 23 Apr 2025 22:05:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE that should only happen in a headless test environment.
> 
> This is a follow-up for https://github.com/openjdk/jfx/pull/1677

Reviewer: @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1793#issuecomment-2835278784

From kcr at openjdk.org  Mon Apr 28 13:41:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 13:41:56 GMT
Subject: RFR: 8341281: Root TreeItem with null value breaks TreeTableView
In-Reply-To: <52nDITR2vfBysnJkmgfkeAmoleGp_rdJiIRj83PqgW4=.8d784c6a-d8f1-4288-b3a2-867041e86197@github.com>
References: <xFhMYdBNp8jVUM490LlNeAMWTYNylVQT6PGgTpwEX9k=.b823c201-10ec-4952-a671-3c3505626231@github.com>
 <52nDITR2vfBysnJkmgfkeAmoleGp_rdJiIRj83PqgW4=.8d784c6a-d8f1-4288-b3a2-867041e86197@github.com>
Message-ID: <8z_CCYwfp_prBX50SAmpHqo_ckZRMUN9RrT6laXHKGg=.b04d4ded-74b5-422b-92ee-0d6fa2ec4f34@github.com>

On Wed, 16 Apr 2025 16:49:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> When the Root TreeItem is set to null, need to relayout to show the children items
>
> if you merge the latest `master` branch it'll get rid of the build error on windows.

Reviewers: @andy-goryachev-oracle @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1767#issuecomment-2835282054

From kcr at openjdk.org  Mon Apr 28 13:42:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 13:42:53 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v2]
In-Reply-To: <Cn4HF7k19uEQvc87CMmoellqid5BxkMOaCwSJnly16E=.dabf462f-74b0-4123-86d0-7a685f689693@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <Cn4HF7k19uEQvc87CMmoellqid5BxkMOaCwSJnly16E=.dabf462f-74b0-4123-86d0-7a685f689693@github.com>
Message-ID: <6Sa2bMwnb7PIM6BKQLmlQcmGe-wVMXo2lhF4FfK1-CM=.dcc64d76-4ff3-489c-b528-dbf75b7c3251@github.com>

On Thu, 17 Apr 2025 16:43:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Tries to address the mystery of missing graphic in the TabPane overflow menu.
>> 
>> ### Summary of Changes
>> 
>> - minor `TabPaneSkin` constructor javadoc clarification
>> - added the property
>> - changed popup menu to be created on demand
>> - removing adding the popup reference to the `TabHeaderSkin` properties (I think it was done for testing purposes, I could not find any references to it in the code)
>>  
>> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java
>> 
>> # Overflow Menu Graphic Property in the TabPaneSkin
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
>> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
>> 
>> 
>> 
>> ## Goals
>> 
>> The goals of this proposal are:
>> 
>> - to allow the application developers to customize the overflow menu items' graphic
>> - retain the backward compatibility with the existing application code
>> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - disable the overflow menu
>> - configure overflow menu graphic property via CSS
>> - add this property to the `TabPane` control itself
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
>> an `ImageView` or `Label` with an `ImageView`.
>> 
>> This limitation makes it impossible for the application developer to use other graphic Nodes,
>> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
>> when the tabs in the `TabPane` have no text.
>> 
>> Example:
>> 
>> 
>> public class TabPaneGraphicFactoryExample {
>>     public void example() {
>>         Tab tab1 = new Tab("Tab1");
>>         tab1.setGraphic(createGraphic(tab1));
>> 
>>         Tab tab2 = new Tab("Tab2");
>>         tab2.setGraphic(createGraphic(tab2));
>> 
>>         TabPane tabPane = new TabPane();
>>         tabPane.getTabs().addAll(tab1, tab2);
>> 
>>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>>         // set overflow menu factory with the same method as was used to create the tabs
>>         skin.setMenuGraphicFactory(this::createGraphic);
>>         tabPane.setSkin(skin);
>>     }
>> 
>>     // creates graphic Nodes for tabs as well as the overflow menu
> ...
>
> 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:
> 
>  - popup menu on demand
>  - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
>  - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
>  - javadoc
>  - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
>  - graphic factory

Reviewers: @arapte @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-2835285041

From angorya at openjdk.org  Mon Apr 28 14:34:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 14:34:03 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
In-Reply-To: <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
Message-ID: <6N_gY2Ewwu7dRlfMaf9I8_WksyrnNxTAkS_B3I9xMzI=.a0b63eea-5762-4455-a801-01cb67fea4be@github.com>

On Mon, 28 Apr 2025 10:32:34 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.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS

Some tests in TableColumnHeaderTest are failing in CI.

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

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

From andy.goryachev at oracle.com  Mon Apr 28 15:36:14 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 28 Apr 2025 15:36:14 +0000
Subject: RichTextArea: how to set wavy underline using CSS?
In-Reply-To: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
References: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
Message-ID: <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>

An interesting question.

Currently, the shape for a wavy underline is created programmatically, see HighlightShape::generateSquiggly().  It is unclear how to enable CSS styling - for example, the model may decide to provide more than one color.  It is also unclear how to generate the necessary path via CSS (it is currently a Path with a sawtooth line segments generated from the underline shape provided by the text layout).

If you are satisfied with the wavy line shape itself and just want to set the color via CSS - that should be easy (you just identified a missing API - there is RichParagraph.Builder.addWavyUnderline(int start, int end, Color color), but not RichParagraph.Builder.addWavyUnderline(int start, int end, String ... styles).

And we have a similar situation with the similar method RichParagraph.Builder.addHighlight().

Could you describe your use case in more detail please?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Sunday, April 27, 2025 at 11:27
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea: how to set wavy underline using CSS?
RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.

However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make all styling via CSS -
I don't want to make users use different mechanisms  for styling (CSS,  code).

Fox example, RichTextFX contains the following rules:

     /* the color of the underline */
     -rtfx-underline-color: <paint>;

     /* the radius used to create waved underline */
     -rtfx-underline-wave-radius: <size>;

Could anyone say how to do it in JFX RichTextArea?

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250428/870651cf/attachment.htm>

From angorya at openjdk.org  Mon Apr 28 15:42:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 15:42:09 GMT
Subject: RFR: 8355615: ConcurrentModificationException creating MenuBar on
 background thread
Message-ID: <5MZeMPmUnR9vJpvjOTSh1OsXPkXaVG4-DKNmzId6jL4=.c871963a-5470-40f3-a2ee-172f6442fe4b@github.com>

Moving MenuBarSkin initialization code to install() which always happens in the FX Application Thread.

Also, ensure that the reverse process also happens in the FX application thread.

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

Commit messages:
 - install

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

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

From pavelturk2000 at gmail.com  Mon Apr 28 15:57:09 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 28 Apr 2025 18:57:09 +0300
Subject: RichTextArea: how to set wavy underline using CSS?
In-Reply-To: <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
 <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <f04b6d4c-f2c7-413d-8a9e-9d36d5331ddf@gmail.com>

Hello, Andy. Thank you for your reply.

I'm working on a project that uses two CodeAreas?one from the RichTextFX project and one from JFX.
I can't provide more details yet, but I promise to share a link once it's ready :)

However, this isn't really the main point. There are two ways to handle styling?via CSS and via code. CSS styling
is always more convenient and preferable since it's an established standard. For example, since my project
involves two CodeAreas, I need to unify their styling approach (using style classes).

Just imagine?for the RTFX CodeArea, a user can use classic CSS, but for the JFX CodeArea, they'd have to come
up with some non-standard approach that would break the whole architecture, relying on workarounds.

That's why I suggest to add wavy underline support to JFX CodeArea. Compare:

Web CSS: text-decoration-style: wavy;
RTFX CSS: -rtfx-underline-wave-radius:?<size>;
JFX CSS: It?s not that simple

Best regards, Pavel

On 4/28/25 18:36, Andy Goryachev wrote:
>
> An interesting question.
>
> Currently, the shape for a wavy underline is created programmatically, see HighlightShape::generateSquiggly().? It is unclear how to enable CSS styling - for example, the model may decide to provide more than one color.? It is also unclear how to generate the necessary path via CSS (it is currently a Path with a sawtooth line segments generated from the underline shape provided by the text layout).
>
> If you are satisfied with the wavy line shape itself and just want to set the color via CSS - that should be easy (you just identified a missing API - there is RichParagraph.Builder.addWavyUnderline(int start, int end, Color color), but not RichParagraph.Builder.addWavyUnderline(int start, int end, String ... styles).
>
> And we have a similar situation with the similar method RichParagraph.Builder.addHighlight().
>
> Could you describe your use case in more detail please?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Sunday, April 27, 2025 at 11:27
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *RichTextArea: how to set wavy underline using CSS?
>
> RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.
>
> However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make?all styling via CSS -
> I don't want to make users use different mechanisms for styling (CSS,? code).
>
> Fox example, RichTextFX contains the following rules:
>
> ???? /* the color of the underline */
> ???? -rtfx-underline-color: <paint>;
>
> ???? /* the radius used to create waved underline */
> ???? -rtfx-underline-wave-radius: <size>;
>
> Could anyone say how to do it in JFX RichTextArea?
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250428/1e15bcd4/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Apr 28 17:00:09 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 28 Apr 2025 17:00:09 +0000
Subject: RichTextArea: how to set wavy underline using CSS?
In-Reply-To: <f04b6d4c-f2c7-413d-8a9e-9d36d5331ddf@gmail.com>
References: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
 <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>
 <f04b6d4c-f2c7-413d-8a9e-9d36d5331ddf@gmail.com>
Message-ID: <BYAPR10MB30131FDA00483F1BF2A7F46AE5812@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you, Pavel, for clarification!

So the use case is merely to style using CSS, but not to define the new and custom ways to render the wavy underline?  In other words, it might be ok to provide a limited set of text decorations (e.g.: solid | double | dotted | dashed | wavy) and allow the model to set style for the color?

I am also curious as to why RichTextFX project provide the capability for -rtfx-underline-wave-radius: <size>; - I mean, what value could that possibly have in terms of the visual difference?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 08:57
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: how to set wavy underline using CSS?
Hello, Andy. Thank you for your reply.

I'm working on a project that uses two CodeAreas?one from the RichTextFX project and one from JFX.
I can't provide more details yet, but I promise to share a link once it's ready :)

However, this isn't really the main point. There are two ways to handle styling?via CSS and via code. CSS styling
is always more convenient and preferable since it's an established standard. For example, since my project
involves two CodeAreas, I need to unify their styling approach (using style classes).

Just imagine?for the RTFX CodeArea, a user can use classic CSS, but for the JFX CodeArea, they'd have to come
up with some non-standard approach that would break the whole architecture, relying on workarounds.

That's why I suggest to add wavy underline support to JFX CodeArea. Compare:

Web CSS: text-decoration-style: wavy;
RTFX CSS: -rtfx-underline-wave-radius: <size>;
JFX CSS: It?s not that simple

Best regards, Pavel
On 4/28/25 18:36, Andy Goryachev wrote:
An interesting question.

Currently, the shape for a wavy underline is created programmatically, see HighlightShape::generateSquiggly().  It is unclear how to enable CSS styling - for example, the model may decide to provide more than one color.  It is also unclear how to generate the necessary path via CSS (it is currently a Path with a sawtooth line segments generated from the underline shape provided by the text layout).

If you are satisfied with the wavy line shape itself and just want to set the color via CSS - that should be easy (you just identified a missing API - there is RichParagraph.Builder.addWavyUnderline(int start, int end, Color color), but not RichParagraph.Builder.addWavyUnderline(int start, int end, String ... styles).

And we have a similar situation with the similar method RichParagraph.Builder.addHighlight().

Could you describe your use case in more detail please?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Sunday, April 27, 2025 at 11:27
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RichTextArea: how to set wavy underline using CSS?
RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.

However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make all styling via CSS -
I don't want to make users use different mechanisms  for styling (CSS,  code).

Fox example, RichTextFX contains the following rules:

     /* the color of the underline */
     -rtfx-underline-color: <paint>;

     /* the radius used to create waved underline */
     -rtfx-underline-wave-radius: <size>;

Could anyone say how to do it in JFX RichTextArea?

Best regards, Pavel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250428/249ea519/attachment.htm>

From lkostyra at openjdk.org  Mon Apr 28 17:06:03 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 28 Apr 2025 17:06:03 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v5]
In-Reply-To: <wE8Qmq3mi_1LTmsJRa2YupRDGXaySqCvYxB1g2SS2Eo=.92257f1e-a56a-47db-a937-d3b7f5fc4b7d@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <Y-_MNA-I1pDaj0eX86VPf9YvFVPmAmtguEluF8xfVuo=.6d6cb1e3-c554-474d-ba9c-3c7470dfb6ba@github.com>
 <UYSjIcLYWuuB8vZ0Le03zuK5Ch06_vB2uR1dDTS1xpo=.2fe4854e-9909-4dc5-8ea1-11b5953d363c@github.com>
 <wE8Qmq3mi_1LTmsJRa2YupRDGXaySqCvYxB1g2SS2Eo=.92257f1e-a56a-47db-a937-d3b7f5fc4b7d@github.com>
Message-ID: <l2DUdjaNjb9EjlYRbQfrAVCtKVztOm3RMYBGdMUXT80=.3f1b06e7-b234-40dd-bf50-5e3cf813d77b@github.com>

On Sat, 26 Apr 2025 14:54:25 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> The `DualWindow` test consistently fails without these changes on my Ubuntu 24.04 test VM, and consistently passes with the changes applied. However, on a physical machine running Ubuntu 24.04, the test passes even without the changes.
> 
> Since I changed the positioning code and it does passes the tests, it might be fixed.

Good news! Problems were usually on slower environments ex. VMs. I would add this test to the list as well, and I'll verify for its stability during my review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-2835909924

From jpereda at openjdk.org  Mon Apr 28 17:27:34 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 17:27:34 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v3]
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: <i2PSm7QqwcxU-rK2NHgiLILa4yxpfXBZC1vw669nUME=.09a2bc36-095c-44da-94b9-5b5a151d1ede@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.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  keep column drag lock

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1754/files
  - new: https://git.openjdk.org/jfx/pull/1754/files/561fcf18..526eb88b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 jpereda at openjdk.org  Mon Apr 28 17:27:34 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 17:27:34 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
In-Reply-To: <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
Message-ID: <mfbuzfZ_LXxD4N4PQowouExB4McE8-gRgrrafMloxKY=.16c784a9-cfd3-41d3-8b1b-3febcd5298b7@github.com>

On Mon, 28 Apr 2025 10:32:34 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.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS

Indeed... this test fails: `TableColumnHeaderTest::testColumnRightClickDoesAllowResizingWhenConsumed`.

It has this JavaDoc:

/**
     * When a right click is done on a table column header and consumed by a self added event handler, the column
     * drag lock should be set to true in the pressed handler, but still to false again in the released handler.<br>
     * By that we guarantee, that the column resizing still works.
     */
  ```
This was changed based on @beldenfox suggestion. I'll change it back.

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

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

From jpereda at openjdk.org  Mon Apr 28 17:30:11 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 17:30:11 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v4]
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: <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@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.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  remove white space

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1754/files
  - new: https://git.openjdk.org/jfx/pull/1754/files/526eb88b..ad478220

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 pavelturk2000 at gmail.com  Mon Apr 28 17:44:59 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Mon, 28 Apr 2025 20:44:59 +0300
Subject: RichTextArea: how to set wavy underline using CSS?
In-Reply-To: <BYAPR10MB30131FDA00483F1BF2A7F46AE5812@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
 <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>
 <f04b6d4c-f2c7-413d-8a9e-9d36d5331ddf@gmail.com>
 <BYAPR10MB30131FDA00483F1BF2A7F46AE5812@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <ec7ce1e2-56a0-4399-89a2-81753ab65e89@gmail.com>


On 4/28/25 20:00, Andy Goryachev wrote:
>
> Thank you, Pavel, for clarification!
>
> So the use case is merely to style using CSS, but not to define the new and custom ways to render the wavy underline?? In other words, it might be ok to provide a limited set of text decorations (e.g.: solid | double | dotted | dashed | wavy) and allow the model to set style for the color?
>

I think it depends on technical capabilities. Of course, if it were possible to adjust the wave radius, that would be great.
On the other hand, as far as I know,? this cannot be done in web CSS. Below, I?ve provided a comparison between web CSS and RTFX CSS.

Web CSS:
<div class="test">Test text</div>
div.test {
 ? text-decoration-line: underline;
 ? text-decoration-style: wavy;
 ? text-decoration-color: red;
 ? text-underline-offset: 10px;
 ? text-decoration-thickness: 3px;
}

RTFX CSS:
 ??????? var codeArea = new CodeArea();
 ??????? var styles = "data:text/css," + ".test { -rtfx-underline-color: red;-rtfx-underline-width: 5px;"
 ??????????????? + "-rtfx-underline-wave-radius: 5;-rtfx-underline-offset: 10px;}";
 ??????? codeArea.getStylesheets().add(styles);
 ??????? codeArea.append("AAAAAAAAAAAAAAAAAAAAAAAAA\n", "test");

See result here: https://ibb.co/wNjWGVrK

So, in web 3 properties - color, width, offset; in RTFX 4 properties - color, width, offset, radius.

I think if initial support is added for these three properties first, that would already make a good solution.
At the same time, wave radius adjustment could be left for the future. Another variant is to add only color
first, leaving all others for the future.
>
> I am also curious as to why RichTextFX project provide the capability for -rtfx-underline-wave-radius:?<size>; - I mean, what value could that possibly have in terms of the visual difference?
>
This is the same RTFX code only with wave radius 10 - see https://ibb.co/35CLrJZY

To set wave radius is important because, for example, default radius in JFX CodeArea
I find too small, for example, I would increase it by 1 or 2. You can compare it to the default
web wave radius.

Best regards, Pavel

> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, April 28, 2025 at 08:57
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RichTextArea: how to set wavy underline using CSS?
>
> Hello, Andy. Thank you for your reply.
>
> I'm working on a project that uses two CodeAreas?one from the RichTextFX project and one from JFX.
> I can't provide more details yet, but I promise to share a link once it's ready :)
>
> However, this isn't really the main point. There are two ways to handle styling?via CSS and via code. CSS styling
> is always more convenient and preferable since it's an established standard. For example, since my project
> involves two CodeAreas, I need to unify their styling approach (using style classes).
>
> Just imagine?for the RTFX CodeArea, a user can use classic CSS, but for the JFX CodeArea, they'd have to come
> up with some non-standard approach that would break the whole architecture, relying on workarounds.
>
> That's why I suggest to add wavy underline support to JFX CodeArea. Compare:
>
> Web CSS: text-decoration-style: wavy;
> RTFX CSS: -rtfx-underline-wave-radius:?<size>;
> JFX CSS: It?s not that simple
>
> Best regards, Pavel
>
> On 4/28/25 18:36, Andy Goryachev wrote:
>
>     An interesting question.
>
>     Currently, the shape for a wavy underline is created programmatically, see HighlightShape::generateSquiggly().? It is unclear how to enable CSS styling - for example, the model may decide to provide more than one color.? It is also unclear how to generate the necessary path via CSS (it is currently a Path with a sawtooth line segments generated from the underline shape provided by the text layout).
>
>     If you are satisfied with the wavy line shape itself and just want to set the color via CSS - that should be easy (you just identified a missing API - there is RichParagraph.Builder.addWavyUnderline(int start, int end, Color color), but not RichParagraph.Builder.addWavyUnderline(int start, int end, String ... styles).
>
>     And we have a similar situation with the similar method RichParagraph.Builder.addHighlight().
>
>     Could you describe your use case in more detail please?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Sunday, April 27, 2025 at 11:27
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *RichTextArea: how to set wavy underline using CSS?
>
>     RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.
>
>     However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make?all styling via CSS -
>     I don't want to make users use different mechanisms? for styling (CSS,? code).
>
>     Fox example, RichTextFX contains the following rules:
>
>     ???? /* the color of the underline */
>     ???? -rtfx-underline-color: <paint>;
>
>     ???? /* the radius used to create waved underline */
>     ???? -rtfx-underline-wave-radius: <size>;
>
>     Could anyone say how to do it in JFX RichTextArea?
>
>     Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250428/bdbb8f7e/attachment-0001.htm>

From mfox at openjdk.org  Mon Apr 28 17:52:27 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 28 Apr 2025 17:52:27 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
Message-ID: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>

On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.

This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.

In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

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

Commit messages:
 - runLater runnables deferred while fullscreen nested event loop is running

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

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

From mstrauss at openjdk.org  Mon Apr 28 17:59:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 28 Apr 2025 17:59:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v47]
In-Reply-To: <eqL_KBGY0wiasR87ueuNR9txNGjWgvJDMcr8S8ytbeQ=.7321498b-0450-489d-9629-7d601377c831@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <YoPav4IxCWPzyPBioZcGQ3O9wjdQJMJkjPUVS-g1RJ0=.3672cbd0-cfa4-484b-80a0-b62cede5f634@github.com>
 <eqL_KBGY0wiasR87ueuNR9txNGjWgvJDMcr8S8ytbeQ=.7321498b-0450-489d-9629-7d601377c831@github.com>
Message-ID: <sZisNqYLMygMeVg1Lhda9DTqx9qtqUyp1n9Da_4Slmk=.ca5c9a79-ea0b-463f-a740-323103b2b530@github.com>

On Tue, 4 Feb 2025 13:17:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add "maximized" pseudo-class for custom maximize button
>
> It looks like this is shaping up nicely. I'll put this on my review queue.
> 
> One thing I wanted to raise is that there are a few new concepts here as well as a reasonably large API surface. This feature seems like a good candidate to release as a Preview Feature (*) to get more feedback on the API before finalizing it. That would mean reviving your [Preview Feature JEP / Draft PR](https://github.com/openjdk/jfx/pull/1359), which you had also mentioned as something to consider in your initial Description of this PR. Do you have any thoughts on this?
> 
> (*) - It can't be an incubator module (at least not without doing something unnatural like creating a subclass of Stage, and that might not even work), since the new API elements and implementation are necessarily in the `javafx.graphics module`.

@kevinrushforth
After several rounds of revision, I think the API is in a good shape by now. Do you have a chance to take a look at it, so that I can continue with the CSR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2836043962

From jpereda at openjdk.org  Mon Apr 28 18:06:55 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 18:06:55 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v4]
In-Reply-To: <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
Message-ID: <G7H6HJvYzpuDExaz0GYbe42iJ38B3DrWT7pgkENMiqE=.cd7b3c4c-a651-4f1d-abe2-61415e56323e@github.com>

On Mon, 28 Apr 2025 17:30:11 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.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove white space

Tests are green now, except for the Windows one, which fails for the `chmodArtifactsSdkWin` task, that seems totally unrelated to this PR.

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

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

From angorya at openjdk.org  Mon Apr 28 18:11:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 18:11:53 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v4]
In-Reply-To: <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
Message-ID: <4H_pHmEi0OSoOVjPE1xaqSg_32hNokkek9LFKZzM0iw=.82898cde-2714-403e-a723-b80c924e8b99@github.com>

On Mon, 28 Apr 2025 17:30:11 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.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove white space

much better, thank you.  btw, you can re-start failing tasks - I hope it's just an intermittent failure.

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

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

From jpereda at openjdk.org  Mon Apr 28 18:27:37 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 18:27:37 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
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: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@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.

Jose Pereda 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 branch 'master' into 8207333-contextmenusort
 - remove white space
 - keep column drag lock
 - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
 - Check popupTrigger on mouse pressed too for tableColumnHeaders

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1754/files
  - new: https://git.openjdk.org/jfx/pull/1754/files/ad478220..bd73bcb7

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

  Stats: 129823 lines in 393 files changed: 34627 ins; 52503 del; 42693 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 jpereda at openjdk.org  Mon Apr 28 18:27:37 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 18:27:37 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v4]
In-Reply-To: <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <Vkkmel38ORhcpkKNUqShWt5zhX-oyvejrjiuksLb6ss=.b89e5c90-4829-40c5-9da5-7f895e2919e6@github.com>
Message-ID: <S6XlR9P-ieZsde5Lz3Cjmvl7VwJwohhRL2Gb4vuqmx0=.7b649006-994e-40c6-8f3d-111122dad47b@github.com>

On Mon, 28 Apr 2025 17:30:11 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.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove white space

It has failed three times in a row. Most likely this has already been fixed with JDK-8354337, so I'll sync from head.

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

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

From jpereda at openjdk.org  Mon Apr 28 18:53:56 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 18:53:56 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <FnwogMVX8KMR58wVMbNR92Gr4W-JAsMxFWDP-plVCww=.2f671641-4e06-4363-bafb-b7ed3dcaea00@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

It is green now (https://github.com/jperedadnr/jfx/actions/runs/14715013268) after I ran again the failed gradle wrapper validation.

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

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

From mfox at openjdk.org  Mon Apr 28 20:05:51 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 28 Apr 2025 20:05:51 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
In-Reply-To: <mfbuzfZ_LXxD4N4PQowouExB4McE8-gRgrrafMloxKY=.16c784a9-cfd3-41d3-8b1b-3febcd5298b7@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
 <mfbuzfZ_LXxD4N4PQowouExB4McE8-gRgrrafMloxKY=.16c784a9-cfd3-41d3-8b1b-3febcd5298b7@github.com>
Message-ID: <3folvS874usH92wbwVZqD5j3pWv_zMWPaRYC_9dVRR4=.4e9743ce-7088-416d-885e-4c0a479f3e00@github.com>

On Mon, 28 Apr 2025 17:24:31 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This was changed based on @beldenfox suggestion. I'll change it back.

If the mouse pressed event triggers a context menu you might never see the mouse released event. So you have to consider what it means if column drag lock gets set and then never cleared.

The failing test strikes me as odd, it is explicitly testing a bit of internal state to verify that a right-click drag operation will work. Users don't expect this to work and overloading right-click makes life complicated so right-click drags are generally disabled even on Windows. I understand that this test case was added because the table header was getting into a persistent bad state but unless I'm missing something (and I certainly might be) the bug should have been resolved by turning right-click drag into a no-op. (It doesn't help that the test uses the MouseEventFirer which sets the isPopupTrigger flag on both pressed and release which doesn't match the behavior of any platform.)

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

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

From vdyakov at openjdk.org  Mon Apr 28 20:15:56 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 28 Apr 2025 20:15:56 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <pw049-lDHLkGpC8MaoR_PZ-ZMyCU4pBF-0fetJrhoYo=.577dd4bc-23fe-4457-bc28-f0e1dfb2ea6c@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

@andy-goryachev-oracle please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2836408264

From kcr at openjdk.org  Mon Apr 28 20:15:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 20:15:57 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <osOdqbCYiGQLlJYTL8fHYTcLmdR_myWxj_lkJYKqCGg=.da860886-2c84-42ca-907a-f95e7f4e51cb@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2836409609

From kcr at openjdk.org  Mon Apr 28 20:25:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 20:25:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <yyNaXtpucgqZS8jlwgjJL-uU1PzfumatXULRhVSytVM=.bebdbcf4-0f86-47ec-9f6b-e95b3d713590@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

This looks like a reasonable solution. I'll put it on my review queue and also do a full headful test run later this week.

A couple quick questions:

* Do you think this will increase the possibility of deadlock?
* Will there be any problem one of the deferred Runnables causes an exitFullScreen (e.g., on a different Stage in a dual screen case)? This might be worth testing.

@andy-goryachev-oracle You might want to test this as well, if you have time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2836446599

From kcr at openjdk.org  Mon Apr 28 20:28:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Apr 2025 20:28:01 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v47]
In-Reply-To: <eqL_KBGY0wiasR87ueuNR9txNGjWgvJDMcr8S8ytbeQ=.7321498b-0450-489d-9629-7d601377c831@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <YoPav4IxCWPzyPBioZcGQ3O9wjdQJMJkjPUVS-g1RJ0=.3672cbd0-cfa4-484b-80a0-b62cede5f634@github.com>
 <eqL_KBGY0wiasR87ueuNR9txNGjWgvJDMcr8S8ytbeQ=.7321498b-0450-489d-9629-7d601377c831@github.com>
Message-ID: <L1D8lm0a2vEM0DEYz9bs8MYNbWiuKkFpVuNucHGjNG0=.e9356032-4f6c-48a4-b39d-bf97267cb219@github.com>

On Tue, 4 Feb 2025 13:17:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add "maximized" pseudo-class for custom maximize button
>
> It looks like this is shaping up nicely. I'll put this on my review queue.
> 
> One thing I wanted to raise is that there are a few new concepts here as well as a reasonably large API surface. This feature seems like a good candidate to release as a Preview Feature (*) to get more feedback on the API before finalizing it. That would mean reviving your [Preview Feature JEP / Draft PR](https://github.com/openjdk/jfx/pull/1359), which you had also mentioned as something to consider in your initial Description of this PR. Do you have any thoughts on this?
> 
> (*) - It can't be an incubator module (at least not without doing something unnatural like creating a subclass of Stage, and that might not even work), since the new API elements and implementation are necessarily in the `javafx.graphics module`.

> @kevinrushforth After several rounds of revision, I think the API is in a good shape by now. Do you have a chance to take a look at it, so that I can continue with the CSR?

Yes, I'll put it on my review queue for this week.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2836455951

From angorya at openjdk.org  Mon Apr 28 20:40:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 20:40:50 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <ZzWehpfiW1N4XGqd4fL0D6ZRZR-6yV8kuE2UDr-dOsc=.989ed3e2-e0eb-4a24-bed1-32732d57f5cf@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

I see a difference in behavior between this PR and the master branch.  Admittedly, the scenario  is weird:

- click and drag a column
- while dragging, right click

What I sort of expect is the behavior of JTable: the right click completes the drag to reorder gesture.

What I see in the master branch is quite weird (testing on macOS): the drag to reorder gesture completes with the column being repositioned, but the popup menu flashes on and then off as the right mouse button is released.

With this PR (again, on macOS) the behavior is different: the popup appears, at the same time the dragging continues uninterrupted.  On Windows, the position of the highlight indicating the column being dragged jumps to the original place after right mouse button is released.

It looks to me as if the original developers did not think of such a scenario (while JTable ones did).

We could deal with this scenario in a separate bug, though I think the Windows case needs to be fixed in this PR.  Alternatively, we might want to handle this weird scenario in this PR.

What do you think?

P.S. I can't test on Linux, and we should probably also test in on the latest Ubuntu as it seems to work slightly different?

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

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

From angorya at openjdk.org  Mon Apr 28 20:56:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 20:56:49 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <UkV9GQ7SwzL6bjQ48Y_DZCIUexxIVHDtnBVS1Wkr_Ck=.13b0d74d-e423-4d4d-a5fa-b74878a4185d@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

the proposed solution makes sense.

question: could this deferral of runnables cause some kind of race condition in respect to other synchronous changes?  Like, for example, trying to hide the window while is being transitioned to or from full screen?

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2836578258

From andy.goryachev at oracle.com  Mon Apr 28 21:05:40 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 28 Apr 2025 21:05:40 +0000
Subject: RichTextArea: how to set wavy underline using CSS?
In-Reply-To: <ec7ce1e2-56a0-4399-89a2-81753ab65e89@gmail.com>
References: <1c68be4f-ce5f-4bee-b578-9bd5931b1ef6@gmail.com>
 <BYAPR10MB3013E230A1C0C726AB89DA38E5812@BYAPR10MB3013.namprd10.prod.outlook.com>
 <f04b6d4c-f2c7-413d-8a9e-9d36d5331ddf@gmail.com>
 <BYAPR10MB30131FDA00483F1BF2A7F46AE5812@BYAPR10MB3013.namprd10.prod.outlook.com>
 <ec7ce1e2-56a0-4399-89a2-81753ab65e89@gmail.com>
Message-ID: <BYAPR10MB301397660565E2D967E90EEBE5812@BYAPR10MB3013.namprd10.prod.outlook.com>

I've created https://bugs.openjdk.org/browse/JDK-8355774 to deal with this enhancement.  Feel free to add your comments.

I guess at the minimum, we should add the missing APIs that enable styling with the CSS (they are present internally, just not exposed via the RichParagraph.Builder, my mistake).

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 10:45
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: how to set wavy underline using CSS?

On 4/28/25 20:00, Andy Goryachev wrote:
Thank you, Pavel, for clarification!

So the use case is merely to style using CSS, but not to define the new and custom ways to render the wavy underline?  In other words, it might be ok to provide a limited set of text decorations (e.g.: solid | double | dotted | dashed | wavy) and allow the model to set style for the color?

I think it depends on technical capabilities. Of course, if it were possible to adjust the wave radius, that would be great.
On the other hand, as far as I know,  this cannot be done in web CSS. Below, I?ve provided a comparison between web CSS and RTFX CSS.

Web CSS:
<div class="test">Test text</div>
div.test {
  text-decoration-line: underline;
  text-decoration-style: wavy;
  text-decoration-color: red;
  text-underline-offset: 10px;
  text-decoration-thickness: 3px;
}

RTFX CSS:
        var codeArea = new CodeArea();
        var styles = "data:text/css," + ".test { -rtfx-underline-color: red;-rtfx-underline-width: 5px;"
                + "-rtfx-underline-wave-radius: 5;-rtfx-underline-offset: 10px;}";
        codeArea.getStylesheets().add(styles);
        codeArea.append("AAAAAAAAAAAAAAAAAAAAAAAAA\n", "test");

See result here: https://ibb.co/wNjWGVrK

So, in web 3 properties - color, width, offset; in RTFX 4 properties - color, width, offset, radius.

I think if initial support is added for these three properties first, that would already make a good solution.
At the same time, wave radius adjustment could be left for the future. Another variant is to add only color
first, leaving all others for the future.

I am also curious as to why RichTextFX project provide the capability for -rtfx-underline-wave-radius: <size>; - I mean, what value could that possibly have in terms of the visual difference?

This is the same RTFX code only with wave radius 10 - see https://ibb.co/35CLrJZY

To set wave radius is important because, for example, default radius in JFX CodeArea
I find too small, for example, I would increase it by 1 or 2. You can compare it to the default
web wave radius.

Best regards, Pavel


-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 08:57
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: how to set wavy underline using CSS?
Hello, Andy. Thank you for your reply.

I'm working on a project that uses two CodeAreas?one from the RichTextFX project and one from JFX.
I can't provide more details yet, but I promise to share a link once it's ready :)

However, this isn't really the main point. There are two ways to handle styling?via CSS and via code. CSS styling
is always more convenient and preferable since it's an established standard. For example, since my project
involves two CodeAreas, I need to unify their styling approach (using style classes).

Just imagine?for the RTFX CodeArea, a user can use classic CSS, but for the JFX CodeArea, they'd have to come
up with some non-standard approach that would break the whole architecture, relying on workarounds.

That's why I suggest to add wavy underline support to JFX CodeArea. Compare:

Web CSS: text-decoration-style: wavy;
RTFX CSS: -rtfx-underline-wave-radius: <size>;
JFX CSS: It?s not that simple

Best regards, Pavel
On 4/28/25 18:36, Andy Goryachev wrote:
An interesting question.

Currently, the shape for a wavy underline is created programmatically, see HighlightShape::generateSquiggly().  It is unclear how to enable CSS styling - for example, the model may decide to provide more than one color.  It is also unclear how to generate the necessary path via CSS (it is currently a Path with a sawtooth line segments generated from the underline shape provided by the text layout).

If you are satisfied with the wavy line shape itself and just want to set the color via CSS - that should be easy (you just identified a missing API - there is RichParagraph.Builder.addWavyUnderline(int start, int end, Color color), but not RichParagraph.Builder.addWavyUnderline(int start, int end, String ... styles).

And we have a similar situation with the similar method RichParagraph.Builder.addHighlight().

Could you describe your use case in more detail please?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Sunday, April 27, 2025 at 11:27
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RichTextArea: how to set wavy underline using CSS?
RichParagraph.Builder has public RichParagraph.Builder addWavyUnderline(int start, int length, Color color) method.

However, I can't find a way how to make a wavy underline via CSS. It is very important for me because I want to make all styling via CSS -
I don't want to make users use different mechanisms  for styling (CSS,  code).

Fox example, RichTextFX contains the following rules:

     /* the color of the underline */
     -rtfx-underline-color: <paint>;

     /* the radius used to create waved underline */
     -rtfx-underline-wave-radius: <size>;

Could anyone say how to do it in JFX RichTextArea?

Best regards, Pavel


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

From angorya at openjdk.org  Mon Apr 28 21:27:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 21:27:50 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <7waiVuGrZZ0lGzBMQGz9IWvduzJ6_74dM4A1tekRqik=.1a3ef4bb-ae42-474f-a768-aba3e240058c@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

Are these changes testable?  If so, could you please describe what we are supposed to see during the testing?

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2836732997

From angorya at openjdk.org  Mon Apr 28 22:52:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Apr 2025 22:52:48 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <Kah3lvcTtrg_GP46DOoK96dTiQqlC91rb-4q3V6Tkak=.d925dd03-bb06-47c0-bd1d-a8536f7d2b3c@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Using the reproducer in the ticket, I could not reproduce the issue with `testDemaximizedPosition()` - it passed in the master branch.

(Just in case, I am going to attach the exact file)

[Stage_RestorePosition_8176813.java.zip](https://github.com/user-attachments/files/19949842/Stage_RestorePosition_8176813.java.zip)

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2836946873

From jpereda at openjdk.org  Mon Apr 28 23:25:51 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 23:25:51 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v2]
In-Reply-To: <3folvS874usH92wbwVZqD5j3pWv_zMWPaRYC_9dVRR4=.4e9743ce-7088-416d-885e-4c0a479f3e00@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <wHz3GRh5g1hsRaLd4VANA6QXLRmjrlOX8Dg8lPEFAUw=.9f9c4061-d179-4ad4-9be8-b32605bf8ff8@github.com>
 <mfbuzfZ_LXxD4N4PQowouExB4McE8-gRgrrafMloxKY=.16c784a9-cfd3-41d3-8b1b-3febcd5298b7@github.com>
 <3folvS874usH92wbwVZqD5j3pWv_zMWPaRYC_9dVRR4=.4e9743ce-7088-416d-885e-4c0a479f3e00@github.com>
Message-ID: <O4jF-YbiyyMU1e4BjZ955OaMludMwbAwkbXtZ8Nx3-E=.ebf86701-5415-4f20-99d2-403bdd2d25b2@github.com>

On Mon, 28 Apr 2025 20:03:24 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Indeed... this test fails: `TableColumnHeaderTest::testColumnRightClickDoesAllowResizingWhenConsumed`.
>> 
>> It has this JavaDoc:
>> 
>> /**
>>      * When a right click is done on a table column header and consumed by a self added event handler, the column
>>      * drag lock should be set to true in the pressed handler, but still to false again in the released handler.<br>
>>      * By that we guarantee, that the column resizing still works.
>>      */
>>   ```
>> This was changed based on @beldenfox suggestion. I'll change it back.
>
>> This was changed based on @beldenfox suggestion. I'll change it back.
> 
> If the mouse pressed event triggers a context menu you might never see the mouse released event. So you have to consider what it means if column drag lock gets set and then never cleared.
> 
> The failing test strikes me as odd, it is explicitly testing a bit of internal state to verify that a right-click drag operation will work. Users don't expect this to work and overloading right-click makes life complicated so right-click drags are generally disabled even on Windows. I understand that this test case was added because the table header was getting into a persistent bad state but unless I'm missing something (and I certainly might be) the bug should have been resolved by turning right-click drag into a no-op. (It doesn't help that the test uses the MouseEventFirer which sets the isPopupTrigger flag on both pressed and release which doesn't match the behavior of any platform.)

@beldenfox I understand your concerns about `columnDragLock` and the related tests `testColumnRightClickDoesAllowResizing()` and `testColumnRightClickDoesAllowResizingWhenConsumed()`, but if I get it right, this PR doesn't really modify the behaviour of such lock.

So I suggest we take this on a follow up issue, revisiting the need to change the lock from true to false when the popup is triggered, and modifying or removing those tests accordingly.

What do you think?

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

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

From jpereda at openjdk.org  Mon Apr 28 23:43:50 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Apr 2025 23:43:50 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <ZzWehpfiW1N4XGqd4fL0D6ZRZR-6yV8kuE2UDr-dOsc=.989ed3e2-e0eb-4a24-bed1-32732d57f5cf@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
 <ZzWehpfiW1N4XGqd4fL0D6ZRZR-6yV8kuE2UDr-dOsc=.989ed3e2-e0eb-4a24-bed1-32732d57f5cf@github.com>
Message-ID: <aCZjHh-76F3eYslP1sdgyJUq6iowMg2c-Ah1-dmUbcs=.54c1e5dd-6cae-4e1c-a823-8730bf3018a9@github.com>

On Mon, 28 Apr 2025 20:38:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>>  - remove white space
>>  - keep column drag lock
>>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>>  - Check popupTrigger on mouse pressed too for tableColumnHeaders
>
> I see a difference in behavior between this PR and the master branch.  Admittedly, the scenario  is weird:
> 
> - click and drag a column
> - while dragging, right click
> 
> What I sort of expect is the behavior of JTable: the right click completes the drag to reorder gesture.
> 
> What I see in the master branch is quite weird (testing on macOS): the drag to reorder gesture completes with the column being repositioned, but the popup menu flashes on and then off as the right mouse button is released.
> 
> With this PR (again, on macOS) the behavior is different: the popup appears, at the same time the dragging continues uninterrupted.  On Windows, the position of the highlight indicating the column being dragged jumps to the original place after right mouse button is released.
> 
> It looks to me as if the original developers did not think of such a scenario (while JTable ones did).
> 
> We could deal with this scenario in a separate bug, though I think the Windows case needs to be fixed in this PR.  Alternatively, we might want to handle this weird scenario in this PR.
> 
> What do you think?
> 
> P.S. I can't test on Linux, and we should probably also test in on the latest Ubuntu as it seems to work slightly different?

@andy-goryachev-oracle About this edge case, on macOS it seems better behaviour after this PR: before the highlighting jumps unexpectedly, while after it, the highlighted area is updated smoothly. And I don't see the popup flashing.
About Windows, do you mean we should try to reproduce the same behaviour as on macOS? I'm not sure this should be part of this PR (the issue was only on macOS/Linux).

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

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

From pavelturk2000 at gmail.com  Mon Apr 28 23:53:53 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 02:53:53 +0300
Subject: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
Message-ID: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>

I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.

To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
 From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.

Something like this:

 ??????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
 ??????????? @Override
 ??????????? public RichParagraph createRichParagraph(CodeTextModel model, int index) {
 ??????????????? if (paragraphStylesAreValid) {
 ??????????????????? return codeArea.getModel().getParagraph(index);
 ??????????????? } else {
 ??? ??? ??? ?????? RichParagraph.Builder b = RichParagraph.builder();
 ?????????????????? ...
 ?????????????????? return b.build();
 ??????????????? }
 ??????????? }

 ??????????? @Override
 ??????????? public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
 ??????????????????? int linesAdded, int charsBottom) {

 ??????????? }
 ??????? });

However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83

As I result I get StackOverflowError. Could anyone say how to do it?

Best regards, Pavel

From kizune at openjdk.org  Tue Apr 29 00:29:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 29 Apr 2025 00:29:51 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <T7Us2HS5nfqfpWngu34D37PTkCfVJQtCcd-64L9y9wE=.f923eb1e-bf6b-4ea1-bf62-d421e53c799e@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <T7Us2HS5nfqfpWngu34D37PTkCfVJQtCcd-64L9y9wE=.f923eb1e-bf6b-4ea1-bf62-d421e53c799e@github.com>
Message-ID: <fDMhuLm4ZNwelz-M52f4_AWKObyFCHq7-6DlNW0Tyqg=.085ed575-e2d6-42ae-88bc-878774187dcc@github.com>

On Mon, 28 Apr 2025 10:29:11 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXProgressIndicatorAccessibility.h line 30:
> 
>> 28: #import <AppKit/NSAccessibility.h>
>> 29: 
>> 30: @interface JFXProgressIndicatorAccessibility :
> 
> Will we use the same interface of ProgressBar? If yes, a comment here mentioning the same would be helpful.

Yes, the same interface is serving ProgressBar and ProgressIndicator.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1796#discussion_r2065118890

From mstrauss at openjdk.org  Tue Apr 29 12:45:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 29 Apr 2025 12:45:25 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v70]
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: <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@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:

  Fix top resize border on Windows

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/6a2f05d6..544d62eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=69
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=68-69

  Stats: 20 lines in 1 file changed: 19 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 duke at openjdk.org  Tue Apr 29 13:47:09 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 29 Apr 2025 13:47:09 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v70]
In-Reply-To: <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
Message-ID: <UuozISbbjtzJd55VrnAgthF-Naph1c8bk7qYIshFOac=.206e501c-e18e-4708-9c8b-2e1e9c26f2b6@github.com>

On Tue, 29 Apr 2025 12:45:25 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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:
> 
>   Fix top resize border on Windows

An issue whereby the top border was not showing re-size cursors when using EXTENDED + HeaderBar, was fixed in https://github.com/openjdk/jfx/pull/1605/commits/544d62eb6dff5ba90e27158dad8a0abe23db8fdf

However, a similar bug is still present when using EXTENDED with **no** HeaderBar, these cursors are missing and it's not possible to re-size using the top border/corners.  Easy to reproduce in Monkey Tester.

It's also impossible to click and drag the window from the header area, in this configuration.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2838984003

From mstrauss at openjdk.org  Tue Apr 29 13:58:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 29 Apr 2025 13:58:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v70]
In-Reply-To: <UuozISbbjtzJd55VrnAgthF-Naph1c8bk7qYIshFOac=.206e501c-e18e-4708-9c8b-2e1e9c26f2b6@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
 <UuozISbbjtzJd55VrnAgthF-Naph1c8bk7qYIshFOac=.206e501c-e18e-4708-9c8b-2e1e9c26f2b6@github.com>
Message-ID: <Sc2N1pkTZti9pVAP0sx5jgeMD4KP_ge-bSKrnt_tbm8=.14e9402e-af95-41a4-b904-f26b7e27a86c@github.com>

On Tue, 29 Apr 2025 13:44:36 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> However, a similar bug is still present when using EXTENDED with **no** HeaderBar, these cursors are missing and it's not possible to re-size using the top border/corners. Easy to reproduce in Monkey Tester.
> 
> It's also impossible to click and drag the window from the header area, in this configuration, which felt like non-native behaviour that could be enabled by default. Maybe it's intentional.

I don't think `EXTENDED` without `HeaderBar` is a supported configuration. The header bar defines the draggable area, and without it, the window doesn't seem to be useful (this would be a resizable but non-movable window). Do you have a specific use case in mind?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2839024657

From duke at openjdk.org  Tue Apr 29 14:17:22 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 29 Apr 2025 14:17:22 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v70]
In-Reply-To: <Sc2N1pkTZti9pVAP0sx5jgeMD4KP_ge-bSKrnt_tbm8=.14e9402e-af95-41a4-b904-f26b7e27a86c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
 <UuozISbbjtzJd55VrnAgthF-Naph1c8bk7qYIshFOac=.206e501c-e18e-4708-9c8b-2e1e9c26f2b6@github.com>
 <Sc2N1pkTZti9pVAP0sx5jgeMD4KP_ge-bSKrnt_tbm8=.14e9402e-af95-41a4-b904-f26b7e27a86c@github.com>
Message-ID: <avC17oXtcZvMlw-4efDZNscDIn81QFVfHRFEKtUJt5Y=.c31f3da2-5f2b-44cb-a71a-c3cdf998eae5@github.com>

On Tue, 29 Apr 2025 13:55:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> > However, a similar bug is still present when using EXTENDED with **no** HeaderBar, these cursors are missing and it's not possible to re-size using the top border/corners. Easy to reproduce in Monkey Tester.
> > It's also impossible to click and drag the window from the header area, in this configuration, which felt like non-native behaviour that could be enabled by default. Maybe it's intentional.
> 
> I don't think `EXTENDED` without `HeaderBar` is a supported configuration. The header bar defines the draggable area, and without it, the window doesn't seem to be useful (this would be a resizable but non-movable window). Do you have a specific use case in mind?

No use case (that I care about), but I was able to create it (Monkey Tester), and it had the minimise/maximise/quit buttons, so it seemed like a "valid" minimalist setup.

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2839094258

From duke at openjdk.org  Tue Apr 29 14:23:05 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 29 Apr 2025 14:23:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v70]
In-Reply-To: <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <B9fv9wOEHwJM8a4vwkiNuefTEWdcmvzLHCoTfx1E8xA=.ad337f4c-5fe5-45be-a779-c352d87e045f@github.com>
Message-ID: <PszjRrIrk4_O4MuRqUm7gKcWksUYFdvAdh9WmbLgPBI=.be77e9a0-c824-4292-8b04-66bcfbcf4655@github.com>

On Tue, 29 Apr 2025 12:45:25 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 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:
> 
>   Fix top resize border on Windows

Another question, can there be some defaults set to prevent this (icons overlapping controls when window is small):

![image](https://github.com/user-attachments/assets/f94f8943-8fe7-4447-9eb2-9fa4094f63aa)

E.g., look what happens when I make IntelliJ as small as possible -- the windowing icons are always visible, never overlap:

![image](https://github.com/user-attachments/assets/e8718602-0283-4a90-9725-0b08a5053ccf)

Same with most apps such as Chrome, etc... everything else shrinks (tabs), but not the windowing icons.

I'm sure a developer can workaround this (I haven't tinkered yet), but it would be good if they didn't need to worry about it...?

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

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2839120508

From angorya at openjdk.org  Tue Apr 29 14:47:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 14:47:56 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <3jzE85Az_o7vkcNCDNf-CtbAuBXwTRxJtIa9prARsUI=.6f7f8787-9baf-42ab-b667-76d4bb870173@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

My immediate thought was we should finish the drag to reorder gesture and avoid showing the popup if the right mouse button is pressed during the drag operation, regardless of the platform (this will change the behavior but I think it makes more sense).  I would recommend doing it as a part of this PR, but it's up to you.

Doing this will also avoid the issue we saw on windows where the highlighted column being dragged jumps suddenly to the original position which is simply wrong.

What do you think?

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

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

From andy.goryachev at oracle.com  Tue Apr 29 15:02:34 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 15:02:34 +0000
Subject: RichTextArea: How to return existing paragraphs from
 SyntaxDecorator?
In-Reply-To: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
References: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
Message-ID: <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

Multiple topics here.

1.  The view does size 100 paragraphs (Params.SLIDING_WINDOW_EXTENT) to ensure smooth scrolling when text wrap is on.  Initially I thought we could allow the application to control this parameter, but we decided against it, as it exposes internal aspect of the implementation.

2. You probably should not cache the paragraphs in the model, or try to optimize the styling in the way I understood you did.  When the view asks for the paragraph, the model needs to render it in all its glory, or things would break.

It looks you are trying to implement the syntax highlighting, right?  The first question you might want to ask is determine whether the styles are known at the time when the paragraph gets requested.  If not - you probably want to return a plain text paragraph, that is with no styling, and once the styling is known, fire the model's style change event, which will cause the view to request the (newly updated) paragraphs it needs.  In other words, the code you supplied won't work - the model should always build a new paragraph (or supply a cached one only if you can guarantee that nothing in it changed, not event line index).

3. Not sure about the scrolling, it seems to work on macOS as expected.  Does it work with a stock model that has none of the "optimizations"?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 16:54
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.

To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
 From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.

Something like this:

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 if (paragraphStylesAreValid) {
                     return codeArea.getModel().getParagraph(index);
                 } else {
                    RichParagraph.Builder b = RichParagraph.builder();
                    ...
                    return b.build();
                 }
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
                     int linesAdded, int charsBottom) {

             }
         });

However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83

As I result I get StackOverflowError. Could anyone say how to do it?

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/7d2843fa/attachment.htm>

From mfox at openjdk.org  Tue Apr 29 15:29:04 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 15:29:04 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <P6tgmtySlZh7H33Gwk_WV0hpa1G-0ZhcC8vNGgCit6g=.dbb93366-19e0-4904-8135-f28194e11a5c@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

I think this PR should probably be accepted as-is. It fixes an obvious problem and doesn't introduce any new ones. Someone should enter a follow-up PR citing some of the other problems but most of those have been around for years and only affect users who are looking for trouble (most wouldn't even consider using the right mouse button to drag).

Here you have separate behavior on click vs drag-click and have to deal with two different approaches to context menus. I've tackled this sort of thing before and it usually takes two or four or six tries to get right. To reduce the complexity you have be aggressive at ignoring irrelevant events (no right-click drag!) and avoid setting up state related to dragging until the user actually starts dragging. So this code needs a modest re-write but, again, it doesn't need to happen in this PR.

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

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

From angorya at openjdk.org  Tue Apr 29 15:29:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 15:29:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <shr-FCRHjFDlArvDmaIwNi8hu63MqM7cvKRQSYGRX5U=.c3226ba6-c304-4773-a340-7bd00016a7f2@github.com>

On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Could we also rename `RestoreStagePositionTest::testUfullscreenPosition`, it might be a typo.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839340778

From pavelturk2000 at gmail.com  Tue Apr 29 15:38:46 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 18:38:46 +0300
Subject: RichTextArea: How to return existing paragraphs from
 SyntaxDecorator?
In-Reply-To: <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
 <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <a04c06a7-f57c-4143-877f-9afaf0bd5a04@gmail.com>

Andy, thank you for your reply

On 4/29/25 18:02, Andy Goryachev wrote:
>
> Multiple topics here.
>
> 1. The view does size 100 paragraphs (Params.SLIDING_WINDOW_EXTENT) to ensure smooth scrolling when text wrap is on.? Initially I thought we could allow the application to control this parameter, but we decided against it, as it exposes internal aspect of the implementation.
>
> 2. You probably should not cache the paragraphs in the model, or try to optimize the styling in the way I understood you did.? When the view asks for the paragraph, the model needs to render it in all its glory, or things would break.
>
> It looks you are trying to implement the syntax highlighting, right?? The first question you might want to ask is determine whether the styles are known at the time when the paragraph gets requested.? If not - you probably want to return a plain text paragraph, that is with no styling, and once the styling is known, fire the model's style change event, which will cause the view to request the (newly updated) paragraphs it needs.? In other words, the code you supplied won't work - the model should always build a new paragraph (or supply a cached one only if you can guarantee that nothing in it changed, not event line index).
>
Hm. I've read this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java#L42 saying that paragraph is IMMUTABLE and decided - why should I recreate it if it hasn't changed. It seems that I was wrong. At the same time in RTFX you can control what to update
and what not. I mean:

public class ParagraphStyler implements Consumer<ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>>> {

 ??? @Override
 ??? public void accept(ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>> lm) {
 ????? //here it is possible to update styles only for paragraphs which styles should be updated
 ?? }
}

codeArea.getVisibleParagraphs().addModificationObserver(new ParagraphStyler()); //only for visible paragraphs!

In other words, JFX CodeArea forces paragraph styles to update whether it?s necessary or not, whereas in RTFX we can optimize this process?at least, that?s how I understand it.

> 3. Not sure about the scrolling, it seems to work on macOS as expected.? Does it work with a stock model that has none of the "optimizations"?
>
> -andy
>

Best regards, Pavel

> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Monday, April 28, 2025 at 16:54
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *RichTextArea: How to return existing paragraphs from SyntaxDecorator?
>
> I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.
>
> To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
> ?From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.
>
> Something like this:
>
> ???????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
> ???????????? @Override
> ???????????? public RichParagraph createRichParagraph(CodeTextModel model, int index) {
> ???????????????? if (paragraphStylesAreValid) {
> ???????????????????? return codeArea.getModel().getParagraph(index);
> ???????????????? } else {
> ???? ??? ??? ?????? RichParagraph.Builder b = RichParagraph.builder();
> ??????????????????? ...
> ??????????????????? return b.build();
> ???????????????? }
> ???????????? }
>
> ???????????? @Override
> ???????????? public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
> ???????????????????? int linesAdded, int charsBottom) {
>
> ???????????? }
> ???????? });
>
> However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83
>
> As I result I get StackOverflowError. Could anyone say how to do it?
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/183c16ac/attachment-0001.htm>

From kcr at openjdk.org  Tue Apr 29 15:41:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Apr 2025 15:41:53 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <P6tgmtySlZh7H33Gwk_WV0hpa1G-0ZhcC8vNGgCit6g=.dbb93366-19e0-4904-8135-f28194e11a5c@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
 <P6tgmtySlZh7H33Gwk_WV0hpa1G-0ZhcC8vNGgCit6g=.dbb93366-19e0-4904-8135-f28194e11a5c@github.com>
Message-ID: <vKJhcn5tDGlImvQjrOdIau-AyUbpysSsIhUhRUg56O4=.8ce9ac19-9851-45d2-a4e0-ac45d27ab853@github.com>

On Tue, 29 Apr 2025 15:26:32 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I think this PR should probably be accepted as-is. It fixes an obvious problem and doesn't introduce any new ones. Someone should enter a follow-up PR citing some of the other problems but most of those have been around for years and only affect users who are looking for trouble ...

I tend to agree, as long as any remaining problems are preexisting and not likely to be encountered in the primary use case.

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

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

From angorya at openjdk.org  Tue Apr 29 16:38:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 16:38:58 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <HlUwmSkrMEqJfwlO9PeFeEd6r8n12vnPs8el1StOYTw=.de6d2957-92b2-471b-a03e-c9b6fff61a4c@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

Marked as reviewed by angorya (Reviewer).

The windows problem is pre-existing.

The after-the-fix behavior is slightly better.  I'll create the follow-up ticket.

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

PR Review: https://git.openjdk.org/jfx/pull/1754#pullrequestreview-2804322000
PR Comment: https://git.openjdk.org/jfx/pull/1754#issuecomment-2839540069

From mfox at openjdk.org  Tue Apr 29 16:42:57 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 16:42:57 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <yyNaXtpucgqZS8jlwgjJL-uU1PzfumatXULRhVSytVM=.bebdbcf4-0f86-47ec-9f6b-e95b3d713590@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <yyNaXtpucgqZS8jlwgjJL-uU1PzfumatXULRhVSytVM=.bebdbcf4-0f86-47ec-9f6b-e95b3d713590@github.com>
Message-ID: <nGEG7kAQL-iQH24GFTU9cKfSolbKA2n8LYMX334g2Q4=.470d2d71-85c8-4964-9818-6aef513a0c7b@github.com>

On Mon, 28 Apr 2025 20:22:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> * Do you think this will increase the possibility of deadlock?

This PR shifts the execution of runLater runnables out to the event loop in effect when setFullScreen() was called. This matches where Windows and Linux would process them. So if we encounter new deadlock conditions we should be seeing them on other platforms.

> * Will there be any problem one of the deferred Runnables causes an exitFullScreen (e.g., on a different Stage in a dual screen case)? This might be worth testing.

Could you provide more details on what you want tested? I'm not that familiar with how fullscreen works on dual screen setups.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839551107

From angorya at openjdk.org  Tue Apr 29 17:01:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 17:01:53 GMT
Subject: RFR: 8207333: [Linux, macOS] Column sorting is triggered always
 after context menu request on table header [v5]
In-Reply-To: <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
References: <NKUD7YBCzfE-hcn7O5G8VkvBUofLe1aD_Uxy7m2JYAs=.cd1106ab-31ae-4718-bcd6-c068dcbf2057@github.com>
 <kiNVg4Ix0gGIw6V6UzefTkQERpXplkPpptz4NVUu_5o=.864039ee-9fa0-476b-8924-a2d971637a86@github.com>
Message-ID: <Y7e20XjZUWV-brwDaoxLEWRppuI1ClLxm3ql62_Y648=.561836dd-8857-4e69-8975-2d5fc24ffe6c@github.com>

On Mon, 28 Apr 2025 18:27:37 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.
>
> Jose Pereda 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 branch 'master' into 8207333-contextmenusort
>  - remove white space
>  - keep column drag lock
>  - Prevent drag or start sorting on if popup is triggered, test ctrl+left click on macOS
>  - Check popupTrigger on mouse pressed too for tableColumnHeaders

created https://bugs.openjdk.org/browse/JDK-8355939

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

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

From mfox at openjdk.org  Tue Apr 29 17:14:52 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 17:14:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <UkV9GQ7SwzL6bjQ48Y_DZCIUexxIVHDtnBVS1Wkr_Ck=.13b0d74d-e423-4d4d-a5fa-b74878a4185d@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <UkV9GQ7SwzL6bjQ48Y_DZCIUexxIVHDtnBVS1Wkr_Ck=.13b0d74d-e423-4d4d-a5fa-b74878a4185d@github.com>
Message-ID: <6Rqo7rm8CKbdJXY9UK-rTZ0--VY-y5sDB1YDtdZMLMA=.9fa507a0-a73f-41ae-a2db-afadb06a074d@github.com>

On Mon, 28 Apr 2025 20:54:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> question: could this deferral of runnables cause some kind of race condition in respect to other synchronous changes? Like, for example, trying to hide the window while is being transitioned to or from full screen?

One of the goals of this PR is to try to avoid making calls on the NSWindow during the transition. In general the OS either rejects the call or it triggers a bug of some sort.

I can only think of two ways for an NSWindow change request to come in during the transition. One is a runLater runnable getting fired by the event loop. This PR fixes that. The other route is if the OS sends us a notification in the middle of the transition. A JavaFX change listener or event handler could make a call that affects the NSWindow. Luckily it looks like the OS takes mercy on us and doesn't send us notifications mid-transition. For example, it doesn't notify us that the NSWindow's size or position has changed until the transition is done. So I think this PR would make it very hard to even attempt to do something like hide the window during the transition.

Beyond that this PR just shifts the execution of these runnables to a later point which matches when they would be executed on Windows or Linux. So if there's an issue with the order in which modifications to the stage are executed I think it would be similar across platforms.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839632677

From andy.goryachev at oracle.com  Tue Apr 29 17:15:27 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 17:15:27 +0000
Subject: RichTextArea: How to return existing paragraphs from
 SyntaxDecorator?
In-Reply-To: <a04c06a7-f57c-4143-877f-9afaf0bd5a04@gmail.com>
References: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
 <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <a04c06a7-f57c-4143-877f-9afaf0bd5a04@gmail.com>
Message-ID: <BYAPR10MB3013DCD90347A292D0663B10E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

If you can guarantee that nothing in the paragraph has changed, the model can return a cached paragraph.

But if the particular paragraph has changed in any way, it might impact other things like the scrollbars.

I suppose it is possible to implement certain optimizations if, for example, the overall dimensions do not change - like, for example, if the style changes only affect the text colors and nothing else.

One can also try to query the view for which paragraphs are visible and which are not, but keep in mind that the same model can be visualized by different views - you should be fine as long as your application can guarantee that there is only one view.

Getting back to syntax highlighting of large models, I envisioned that the background thread that computes the highlighting updates the model periodically and in (large) blocks, to minimize the load, and to strike the balance between quality and performance.  Also, when dealing with large text that might contain comments, the syntax highlighter may want to keep track of the nexus points from which the syntax computation can be re-started instead of re-scanning the file from the beginning.  All this might get complicated rather quickly though.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 08:39
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
Andy, thank you for your reply
On 4/29/25 18:02, Andy Goryachev wrote:
Multiple topics here.

1.  The view does size 100 paragraphs (Params.SLIDING_WINDOW_EXTENT) to ensure smooth scrolling when text wrap is on.  Initially I thought we could allow the application to control this parameter, but we decided against it, as it exposes internal aspect of the implementation.

2. You probably should not cache the paragraphs in the model, or try to optimize the styling in the way I understood you did.  When the view asks for the paragraph, the model needs to render it in all its glory, or things would break.

It looks you are trying to implement the syntax highlighting, right?  The first question you might want to ask is determine whether the styles are known at the time when the paragraph gets requested.  If not - you probably want to return a plain text paragraph, that is with no styling, and once the styling is known, fire the model's style change event, which will cause the view to request the (newly updated) paragraphs it needs.  In other words, the code you supplied won't work - the model should always build a new paragraph (or supply a cached one only if you can guarantee that nothing in it changed, not event line index).
Hm. I've read this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java#L42 saying that paragraph is IMMUTABLE and decided - why should I recreate it if it hasn't changed. It seems that I was wrong. At the same time in RTFX you can control what to update
and what not. I mean:

public class ParagraphStyler implements Consumer<ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>>> {

    @Override
    public void accept(ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>> lm) {
      //here it is possible to update styles only for paragraphs which styles should be updated
   }
}

codeArea.getVisibleParagraphs().addModificationObserver(new ParagraphStyler()); //only for visible paragraphs!

In other words, JFX CodeArea forces paragraph styles to update whether it?s necessary or not, whereas in RTFX we can optimize this process?at least, that?s how I understand it.



3. Not sure about the scrolling, it seems to work on macOS as expected.  Does it work with a stock model that has none of the "optimizations"?

-andy


Best regards, Pavel



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 16:54
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.

To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
 From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.

Something like this:

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 if (paragraphStylesAreValid) {
                     return codeArea.getModel().getParagraph(index);
                 } else {
                    RichParagraph.Builder b = RichParagraph.builder();
                    ...
                    return b.build();
                 }
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
                     int linesAdded, int charsBottom) {

             }
         });

However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83

As I result I get StackOverflowError. Could anyone say how to do it?

Best regards, Pavel

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

From mfox at openjdk.org  Tue Apr 29 17:19:55 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 17:19:55 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <Kah3lvcTtrg_GP46DOoK96dTiQqlC91rb-4q3V6Tkak=.d925dd03-bb06-47c0-bd1d-a8536f7d2b3c@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <Kah3lvcTtrg_GP46DOoK96dTiQqlC91rb-4q3V6Tkak=.d925dd03-bb06-47c0-bd1d-a8536f7d2b3c@github.com>
Message-ID: <Weo3mLkxVKs3TC3f_5xuiKLqmNEwyx3wSXJcWFv4Big=.9765df3e-8ded-47da-a139-495119ee60d6@github.com>

On Mon, 28 Apr 2025 22:49:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using the reproducer in the ticket, I could not reproduce the issue with `testDemaximizedPosition()` - it passed in the master branch.

You're right, it should work. The test is still disabled on macOS even though the blocking bug was fixed a while ago.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839643912

From angorya at openjdk.org  Tue Apr 29 17:22:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 17:22:48 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <Weo3mLkxVKs3TC3f_5xuiKLqmNEwyx3wSXJcWFv4Big=.9765df3e-8ded-47da-a139-495119ee60d6@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <Kah3lvcTtrg_GP46DOoK96dTiQqlC91rb-4q3V6Tkak=.d925dd03-bb06-47c0-bd1d-a8536f7d2b3c@github.com>
 <Weo3mLkxVKs3TC3f_5xuiKLqmNEwyx3wSXJcWFv4Big=.9765df3e-8ded-47da-a139-495119ee60d6@github.com>
Message-ID: <c3onP-CpT9GxtIsE2QoVaRGvv8m-mDY6TqObMTqO8eA=.0cbebe10-3a3e-458b-9c65-89d838cac367@github.com>

On Tue, 29 Apr 2025 17:17:28 GMT, Martin Fox <mfox at openjdk.org> wrote:

> testDemaximizedPosition()

sorry, I meant with the standalone reproducer, not the actual test.  see here
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/Stage_RestorePosition_8176813.java

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839649625

From mfox at openjdk.org  Tue Apr 29 17:29:26 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 17:29:26 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v2]
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo, re-enabled maximized position test on macOS.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1797/files
  - new: https://git.openjdk.org/jfx/pull/1797/files/1e71ff3e..54cc8a3f

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

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

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

From mfox at openjdk.org  Tue Apr 29 17:42:49 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 17:42:49 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases
In-Reply-To: <c3onP-CpT9GxtIsE2QoVaRGvv8m-mDY6TqObMTqO8eA=.0cbebe10-3a3e-458b-9c65-89d838cac367@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <Kah3lvcTtrg_GP46DOoK96dTiQqlC91rb-4q3V6Tkak=.d925dd03-bb06-47c0-bd1d-a8536f7d2b3c@github.com>
 <Weo3mLkxVKs3TC3f_5xuiKLqmNEwyx3wSXJcWFv4Big=.9765df3e-8ded-47da-a139-495119ee60d6@github.com>
 <c3onP-CpT9GxtIsE2QoVaRGvv8m-mDY6TqObMTqO8eA=.0cbebe10-3a3e-458b-9c65-89d838cac367@github.com>
Message-ID: <x4tBBPihcwSMADYHQK4EUvN3oaMTKb9BRBISsOnWXng=.cceb25df-8a59-49f6-a96d-54cd5876c78e@github.com>

On Tue, 29 Apr 2025 17:20:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > testDemaximizedPosition()
> 
> sorry, I meant with the standalone reproducer, not the actual test.

The standalone reproducer is just a slightly tweaked version of the system test. Both should work fine. The system test should have been re-enabled years ago when JDK-8089230 was resolved.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839694180

From angorya at openjdk.org  Tue Apr 29 17:42:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 17:42:50 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v2]
In-Reply-To: <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
Message-ID: <J4PtI9vFsBQdUuSKfQTwpnQl2lKOGpsJ_SycChlRfAI=.6b350252-ff11-442c-8afd-aa4493c11aad@github.com>

On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo, re-enabled maximized position test on macOS.

I modified the reproducer to invoke each test 10 times:


    public static void launch() throws Exception {
        initFX();
        try {
            Stage_RestorePosition_8176813 test = new Stage_RestorePosition_8176813();
            t(() -> test.testUnfullscreenPosition());
            t(() -> test.testDemaximizedPosition());
        } catch (Throwable e) {
            e.printStackTrace();
        } finally {
            teardown();
        }
    }
    
    interface Ru {
        public void run() throws Exception;
    }

    static void t(Ru r) throws Exception {
        for (int i = 0; i < 10; i++) {
            r.run();
        }
    }


getting an exception, intermittently, in the middle of the test:


java.lang.AssertionError: Assertion failed: expected true, was false
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.fail(Stage_RestorePosition_8176813.java:70)
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.assertTrue(Stage_RestorePosition_8176813.java:75)
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.testUnfullscreenPosition(Stage_RestorePosition_8176813.java:129)
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.lambda$0(Stage_RestorePosition_8176813.java:50)
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.t(Stage_RestorePosition_8176813.java:65)
	at andy_test/goryachev.bugs.Stage_RestorePosition_8176813.launch(Stage_RestorePosition_8176813.java:50)
	at andy_test/goryachev.apps.AppTestLauncher.main(AppTestLauncher.java:15)


see 
https://github.com/andy-goryachev-oracle/Test/commit/4344eb949900642f000215625b59f10e9d737340

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839698724

From angorya at openjdk.org  Tue Apr 29 17:49:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 17:49:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v2]
In-Reply-To: <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
Message-ID: <UYQGZ-7Wu5qaPjaCK6hmgymgNLrzTEMVdgP6kw6U3ks=.45d9c011-0d5c-472e-aae0-db2ab0695937@github.com>

On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo, re-enabled maximized position test on macOS.

it's possible that 200/400 ms is just too short.

increased the timeout to 700 ms, seems to produce no exceptions:

https://github.com/andy-goryachev-oracle/Test/commit/18c77fd93925c51d6c2b5d7b590ececcea8d1e0c

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839715356
PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2839719427

From pavelturk2000 at gmail.com  Tue Apr 29 17:53:20 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 20:53:20 +0300
Subject: RichTextArea: How to return existing paragraphs from
 SyntaxDecorator?
In-Reply-To: <BYAPR10MB3013DCD90347A292D0663B10E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
 <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <a04c06a7-f57c-4143-877f-9afaf0bd5a04@gmail.com>
 <BYAPR10MB3013DCD90347A292D0663B10E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <c055b325-a85b-4110-a458-3b54744df78a@gmail.com>

Thank you very much for such detailed answer!

On 4/29/25 20:15, Andy Goryachev wrote:
>
> If you can guarantee that nothing in the paragraph has changed, the model can return a cached paragraph.
>
The problem is it doesn't return. As I've said earlier the problem is in this line - However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83 and as a result -> StackOverflow.

> But if the particular paragraph has changed in any way, it might impact other things like the scrollbars.
>
> I suppose it is possible to implement certain optimizations if, for example, the overall dimensions do not change - like, for example, if the style changes only affect the text colors and nothing else.
>
> One can also try to query the view for which paragraphs are visible and which are not, but keep in mind that the same model can be visualized by different views - you should be fine as long as your application can guarantee that there is only one view.
>
> Getting back to syntax highlighting of large models, I envisioned that the background thread that computes the highlighting updates the model periodically and in (large) blocks, to minimize the load, and to strike the balance between quality and performance.? Also, when dealing with large text that might contain comments, the syntax highlighter may want to keep track of the nexus points from which the syntax computation can be re-started instead of re-scanning the file from the beginning.? All this might get complicated rather quickly though.
>

Yes, I am working on highlighting now and I add highlighting in SyntaxDecorator on JavaFX thread:

 ???????????? @Override
 ???????????? public RichParagraph createRichParagraph(CodeTextModel model, int index) {
 ???? ??? ??? ?????? RichParagraph.Builder b = RichParagraph.builder();
 ??????????????????? for (segment: segments) {
b.addWithStyleNames(segment.getText(), segment.getStyles().toArray(String[]::new));
 ? ? ? ? ? ? ? ? ? ? }
 ??????????????????? return b.build();
 ???????????????? }
 ???????????? }

Important! I use only style classes (no java, no inline style).

Segments - already ready model. Can such code create performance problems, including scrolling? I mean, that as I understand there are TWO ways to add styles:
1) on JavaFX thread 2) on background thread. I optimized my code model (providing ready segments) to the maximum, and I think the code must work well on JavaFX thread.
But it doesn't - I tested code with about 6 000 paragraphs. At the same time the same approach works without performance problems in RTFX.

Best regards, Pavel

> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Tuesday, April 29, 2025 at 08:39
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
>
> Andy, thank you for your reply
>
> On 4/29/25 18:02, Andy Goryachev wrote:
>
>     Multiple topics here.
>
>     1. The view does size 100 paragraphs (Params.SLIDING_WINDOW_EXTENT) to ensure smooth scrolling when text wrap is on.? Initially I thought we could allow the application to control this parameter, but we decided against it, as it exposes internal aspect of the implementation.
>
>     2. You probably should not cache the paragraphs in the model, or try to optimize the styling in the way I understood you did.? When the view asks for the paragraph, the model needs to render it in all its glory, or things would break.
>
>     It looks you are trying to implement the syntax highlighting, right?? The first question you might want to ask is determine whether the styles are known at the time when the paragraph gets requested.? If not - you probably want to return a plain text paragraph, that is with no styling, and once the styling is known, fire the model's style change event, which will cause the view to request the (newly updated) paragraphs it needs.? In other words, the code you supplied won't work - the model should always build a new paragraph (or supply a cached one only if you can guarantee that nothing in it changed, not event line index).
>
> Hm. I've read this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java#L42 saying that paragraph is IMMUTABLE and decided - why should I recreate it if it hasn't changed. It seems that I was wrong. At the same time in RTFX you can control what to update
> and what not. I mean:
>
> public class ParagraphStyler implements Consumer<ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>>> {
>
> ??? @Override
> ??? public void accept(ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>> lm) {
> ????? //here it is possible to update styles only for paragraphs which styles should be updated
> ?? }
> }
>
> codeArea.getVisibleParagraphs().addModificationObserver(new ParagraphStyler()); //only for visible paragraphs!
>
> In other words, JFX CodeArea forces paragraph styles to update whether it?s necessary or not, whereas in RTFX we can optimize this process?at least, that?s how I understand it.
>
>
>     3. Not sure about the scrolling, it seems to work on macOS as expected.? Does it work with a stock model that has none of the "optimizations"?
>
>     -andy
>
>
> Best regards, Pavel
>
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Monday, April 28, 2025 at 16:54
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *RichTextArea: How to return existing paragraphs from SyntaxDecorator?
>
>     I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.
>
>     To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
>     ?From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.
>
>     Something like this:
>
>     ???????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
>     ???????????? @Override
>     ???????????? public RichParagraph createRichParagraph(CodeTextModel model, int index) {
>     ???????????????? if (paragraphStylesAreValid) {
>     ???????????????????? return codeArea.getModel().getParagraph(index);
>     ???????????????? } else {
>     ???? ??? ??? ?????? RichParagraph.Builder b = RichParagraph.builder();
>     ??????????????????? ...
>     ??????????????????? return b.build();
>     ???????????????? }
>     ???????????? }
>
>     ???????????? @Override
>     ???????????? public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
>     ???????????????????? int linesAdded, int charsBottom) {
>
>     ???????????? }
>     ???????? });
>
>     However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83
>
>     As I result I get StackOverflowError. Could anyone say how to do it?
>
>     Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/6730749e/attachment-0001.htm>

From andy.goryachev at oracle.com  Tue Apr 29 18:04:15 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 18:04:15 +0000
Subject: RichTextArea: How to return existing paragraphs from
 SyntaxDecorator?
In-Reply-To: <c055b325-a85b-4110-a458-3b54744df78a@gmail.com>
References: <41a9791e-7356-4bbd-81d4-f92838b8fcad@gmail.com>
 <BYAPR10MB3013DB00B4D0D317F25BE9F1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <a04c06a7-f57c-4143-877f-9afaf0bd5a04@gmail.com>
 <BYAPR10MB3013DCD90347A292D0663B10E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c055b325-a85b-4110-a458-3b54744df78a@gmail.com>
Message-ID: <BYAPR10MB301371A32251C3810CD0B4F3E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

You *do not* want to update javaFX in a background thread.

The idea is to compute the syntax in a background thread (provided the underlying model is properly synchronized and can serve the plain text paragraphs to multiple threads), but the actual change must take effect in the FX application thread.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 10:54
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
Thank you very much for such detailed answer!
On 4/29/25 20:15, Andy Goryachev wrote:
If you can guarantee that nothing in the paragraph has changed, the model can return a cached paragraph.
The problem is it doesn't return. As I've said earlier the problem is in this line - However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83  and as a result -> StackOverflow.



But if the particular paragraph has changed in any way, it might impact other things like the scrollbars.

I suppose it is possible to implement certain optimizations if, for example, the overall dimensions do not change - like, for example, if the style changes only affect the text colors and nothing else.

One can also try to query the view for which paragraphs are visible and which are not, but keep in mind that the same model can be visualized by different views - you should be fine as long as your application can guarantee that there is only one view.

Getting back to syntax highlighting of large models, I envisioned that the background thread that computes the highlighting updates the model periodically and in (large) blocks, to minimize the load, and to strike the balance between quality and performance.  Also, when dealing with large text that might contain comments, the syntax highlighter may want to keep track of the nexus points from which the syntax computation can be re-started instead of re-scanning the file from the beginning.  All this might get complicated rather quickly though.


Yes, I am working on highlighting now and I add highlighting in SyntaxDecorator on JavaFX thread:

             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                    RichParagraph.Builder b = RichParagraph.builder();
                    for (segment: segments) {
                           b.addWithStyleNames(segment.getText(), segment.getStyles().toArray(String[]::new));
                    }
                    return b.build();
                 }
             }

Important! I use only style classes (no java, no inline style).

Segments - already ready model. Can such code create performance problems, including scrolling? I mean, that as I understand there are TWO ways to add styles:
1) on JavaFX thread 2) on background thread. I optimized my code model (providing ready segments) to the maximum, and I think the code must work well on JavaFX thread.
But it doesn't - I tested code with about 6 000 paragraphs. At the same time the same approach works without performance problems in RTFX.

Best regards, Pavel


-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 08:39
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
Andy, thank you for your reply
On 4/29/25 18:02, Andy Goryachev wrote:
Multiple topics here.

1.  The view does size 100 paragraphs (Params.SLIDING_WINDOW_EXTENT) to ensure smooth scrolling when text wrap is on.  Initially I thought we could allow the application to control this parameter, but we decided against it, as it exposes internal aspect of the implementation.

2. You probably should not cache the paragraphs in the model, or try to optimize the styling in the way I understood you did.  When the view asks for the paragraph, the model needs to render it in all its glory, or things would break.

It looks you are trying to implement the syntax highlighting, right?  The first question you might want to ask is determine whether the styles are known at the time when the paragraph gets requested.  If not - you probably want to return a plain text paragraph, that is with no styling, and once the styling is known, fire the model's style change event, which will cause the view to request the (newly updated) paragraphs it needs.  In other words, the code you supplied won't work - the model should always build a new paragraph (or supply a cached one only if you can guarantee that nothing in it changed, not event line index).
Hm. I've read this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java#L42 saying that paragraph is IMMUTABLE and decided - why should I recreate it if it hasn't changed. It seems that I was wrong. At the same time in RTFX you can control what to update
and what not. I mean:

public class ParagraphStyler implements Consumer<ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>>> {

    @Override
    public void accept(ListModification<? extends Paragraph<Collection<String>, String, Collection<String>>> lm) {
      //here it is possible to update styles only for paragraphs which styles should be updated
   }
}

codeArea.getVisibleParagraphs().addModificationObserver(new ParagraphStyler()); //only for visible paragraphs!

In other words, JFX CodeArea forces paragraph styles to update whether it?s necessary or not, whereas in RTFX we can optimize this process?at least, that?s how I understand it.


3. Not sure about the scrolling, it seems to work on macOS as expected.  Does it work with a stock model that has none of the "optimizations"?

-andy


Best regards, Pavel


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Monday, April 28, 2025 at 16:54
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: RichTextArea: How to return existing paragraphs from SyntaxDecorator?
I noticed that paragraphs in CodeArea are updated too aggressively. For example, when I press a single key like '1', about 100 paragraphs get refreshed.

To improve performance, I decided to implement it this way: I store information for each paragraph indicating whether its styles are up-to-date or not.
 From SyntaxDecorator, I return the existing paragraph from the model if the styles are valid. If the styles are outdated, I build a new paragraph.

Something like this:

         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel model, int index) {
                 if (paragraphStylesAreValid) {
                     return codeArea.getModel().getParagraph(index);
                 } else {
                    RichParagraph.Builder b = RichParagraph.builder();
                    ...
                    return b.build();
                 }
             }

             @Override
             public void handleChange(CodeTextModel m, TextPos start, TextPos end, int charsTop,
                     int linesAdded, int charsBottom) {

             }
         });

However, it didn't work because of this line - https://github.com/openjdk/jfx/blob/3fdd21386d6db96294fcecd80afc25d09732c067/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/CodeTextModel.java#L83

As I result I get StackOverflowError. Could anyone say how to do it?

Best regards, Pavel


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

From mfox at openjdk.org  Tue Apr 29 18:49:01 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Apr 2025 18:49:01 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v9]
In-Reply-To: <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <gzgRzdfNVjw48zIngXk22Xt8Br_IgU2w7yMmvbaqPRI=.029c857d-2552-46a6-94b5-e1420857ce29@github.com>
Message-ID: <8xPy_DAa_f26DcpvFwoBc82uXGsQHejDI55bpbrIfK8=.8d871d7a-6569-44c4-92eb-7ed413f16616@github.com>

On Sat, 26 Apr 2025 19:01:13 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> 
>> Overall, it has been made more robust within its scope, particularly in terms of sizing, positioning, and state management.
>> 
>> List of changes:
>> 1. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 3. States (fullscreen, maximized and iconify) are now reported back to Java when it actually happens rather than immediately (except when not realized);
>> 4. When a window is maximized, it will ignore geometry changes and restore to the geometry it had prior to being maximized. After some testing, I believe this is the best behavior for platform compatibility;
>> 5. Unifies the WindowContext class: previously, there were three separate classes?two of which (for applets and Java Web Start) were removed, leaving only one. However, the supporting infrastructure was still there partially. [Unify WindowContext in glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768)
>> 6. Tests were added and re-enabled to ensure everything works correctly. The stage tests now cover various StageStyle configurations, as I found that `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` stages;
>> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`;
>> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. 
>> 
>> A simple manual test is also provided but I would prefer to move it's functionality to monkey tester:
>> `java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 2. [[Linux] Intermittent test failure in IconifyTest.ca...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old comment

tests/system/src/test/java/test/robot/javafx/stage/StageAttributesTest.java line 312:

> 310:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
> 311:     @EnumSource(names = {"DECORATED", "UNDECORATED"})
> 312:     void testStageStatePrecedenceOrderIconifiedMaximizedBeforeShow(StageStyle stageStyle) throws InterruptedException {

The precedence rules written into the spec are very problematic and it would be a bear to implement them. For example, if you attempt to maximize an iconified stage on Windows it will de-iconify. Making it stay iconified and maximize later would take real effort. Maximizing an iconified stage on Mac does nothing (glass loses the maximized state) and fixing that would also take a lot of work. I really think our time would be better spent leaving things as-is and updating the spec.

I don't think the API calls for maximizing and iconifying the stage are useful to begin with. These are features provided to users so they can manager their desktop real estate. There's not a lot of compelling use cases for apps to do this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2067143320

From pavelturk2000 at gmail.com  Tue Apr 29 19:11:46 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 22:11:46 +0300
Subject: RichTextArea: does CodeArea support code folding?
Message-ID: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>

RTFX CodeArea has methods for code folding:

codeArea.foldParagraphs(int, int)
codeArea.unfoldParagraphs(int);

However, I can't find something with 'fold' in https://download.java.net/java/early_access/javafx25/docs/api/jfx.incubator.richtext/jfx/incubator/scene/control/richtext/CodeArea.html

Could anyone say what methods are used for folding (if JFX CodeArea supports it).

Best regards, Pavel

From andy.goryachev at oracle.com  Tue Apr 29 19:24:38 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 19:24:38 +0000
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
Message-ID: <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

Code folding is not currently supported by the CodeArea, at least with the models provided.

It might be possible to implement the folding in a custom component, using the following steps:

- implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
- implement a model that knows how to fold, and exposes the folding APIs
- modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.

I suppose it's possible to fold these features into the stock CodeArea, given sufficient interest from the community.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 12:12
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea: does CodeArea support code folding?
RTFX CodeArea has methods for code folding:

codeArea.foldParagraphs(int, int)
codeArea.unfoldParagraphs(int);

However, I can't find something with 'fold' in https://download.java.net/java/early_access/javafx25/docs/api/jfx.incubator.richtext/jfx/incubator/scene/control/richtext/CodeArea.html

Could anyone say what methods are used for folding (if JFX CodeArea supports it).

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/95387300/attachment-0001.htm>

From pavelturk2000 at gmail.com  Tue Apr 29 19:46:55 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 22:46:55 +0300
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>

I believe the community's interest in this feature can be demonstrated with three simple arguments:

1. The amount of code needed to implement what you described is comparable to the size of the existing CodeArea itself.
2. This feature already exists in RichTextFX (JavaFX) and RSyntaxTextArea (Swing).
3. It?s also present in editors like NetBeans, IntelliJ IDEA, and VS Code.

So, I think there?s every reason to add it to JFX CodeArea as well.

Best regards, Pavel

On 4/29/25 22:24, Andy Goryachev wrote:
>
> Code folding is not currently supported by the CodeArea, at least with the models provided.
>
> It might be possible to implement the folding in a custom component, using the following steps:
>
> - implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
>
> - implement a model that knows how to fold, and exposes the folding APIs
>
> - modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.
>
> I suppose it's possible to /fold/ these features into the stock CodeArea, given sufficient interest from the community.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/33239763/attachment.htm>

From andy.goryachev at oracle.com  Tue Apr 29 19:52:32 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 19:52:32 +0000
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
Message-ID: <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

I do not disagree.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 12:47
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: does CodeArea support code folding?
I believe the community's interest in this feature can be demonstrated with three simple arguments:

1. The amount of code needed to implement what you described is comparable to the size of the existing CodeArea itself.
2. This feature already exists in RichTextFX (JavaFX) and RSyntaxTextArea (Swing).
3. It?s also present in editors like NetBeans, IntelliJ IDEA, and VS Code.

So, I think there?s every reason to add it to JFX CodeArea as well.

Best regards, Pavel
On 4/29/25 22:24, Andy Goryachev wrote:
Code folding is not currently supported by the CodeArea, at least with the models provided.

It might be possible to implement the folding in a custom component, using the following steps:

- implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
- implement a model that knows how to fold, and exposes the folding APIs
- modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.

I suppose it's possible to fold these features into the stock CodeArea, given sufficient interest from the community.


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

From angorya at openjdk.org  Tue Apr 29 20:54:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Apr 2025 20:54:51 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v2]
In-Reply-To: <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <mmYZQotMjgb-pHSRB2x6WPd7kZa3uA2AGe-AvGlwKAk=.006a7940-9b26-4d37-b43c-1fb57e7c2f4f@github.com>
Message-ID: <2kgg50phaCAHKhq0YnoPEDTsEZLi8zlcGatuuJ8GhN0=.c8eb518d-b4f6-4eda-a510-cf1a2c474b21@github.com>

On Tue, 29 Apr 2025 17:29:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo, re-enabled maximized position test on macOS.

my testing looks good.

I'd suggest to double the timeout in `RestoreStagePositionTest::testUnfullscreenPosition()` (line 95) to 800ms since I was getting exceptions during testing.

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

Changes requested by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1797#pullrequestreview-2805060147

From pavelturk2000 at gmail.com  Tue Apr 29 20:56:17 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Tue, 29 Apr 2025 23:56:17 +0300
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
 <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <c264fd60-e311-4851-ae23-34ffc3e67368@gmail.com>

I've just opened an issue about code folding.

Best regards, Pavel

On 4/29/25 22:52, Andy Goryachev wrote:
>
> I do not disagree.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Tuesday, April 29, 2025 at 12:47
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RichTextArea: does CodeArea support code folding?
>
> I believe the community's interest in this feature can be demonstrated with three simple arguments:
>
> 1. The amount of code needed to implement what you described is comparable to the size of the existing CodeArea itself.
> 2. This feature already exists in RichTextFX (JavaFX) and RSyntaxTextArea (Swing).
> 3. It?s also present in editors like NetBeans, IntelliJ IDEA, and VS Code.
>
> So, I think there?s every reason to add it to JFX CodeArea as well.
>
> Best regards, Pavel
>
> On 4/29/25 22:24, Andy Goryachev wrote:
>
>     Code folding is not currently supported by the CodeArea, at least with the models provided.
>
>     It might be possible to implement the folding in a custom component, using the following steps:
>
>     - implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
>
>     - implement a model that knows how to fold, and exposes the folding APIs
>
>     - modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.
>
>     I suppose it's possible to /fold/ these features into the stock CodeArea, given sufficient interest from the community.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/04492ee9/attachment.htm>

From andy.goryachev at oracle.com  Tue Apr 29 21:02:35 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 29 Apr 2025 21:02:35 +0000
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <c264fd60-e311-4851-ae23-34ffc3e67368@gmail.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
 <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c264fd60-e311-4851-ae23-34ffc3e67368@gmail.com>
Message-ID: <BYAPR10MB3013108DE93372E9EE05ACB3E5802@BYAPR10MB3013.namprd10.prod.outlook.com>

In JBS?  What's the link?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 13:56
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: does CodeArea support code folding?
I've just opened an issue about code folding.

Best regards, Pavel
On 4/29/25 22:52, Andy Goryachev wrote:
I do not disagree.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Tuesday, April 29, 2025 at 12:47
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: does CodeArea support code folding?
I believe the community's interest in this feature can be demonstrated with three simple arguments:

1. The amount of code needed to implement what you described is comparable to the size of the existing CodeArea itself.
2. This feature already exists in RichTextFX (JavaFX) and RSyntaxTextArea (Swing).
3. It?s also present in editors like NetBeans, IntelliJ IDEA, and VS Code.

So, I think there?s every reason to add it to JFX CodeArea as well.

Best regards, Pavel
On 4/29/25 22:24, Andy Goryachev wrote:
Code folding is not currently supported by the CodeArea, at least with the models provided.

It might be possible to implement the folding in a custom component, using the following steps:

- implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
- implement a model that knows how to fold, and exposes the folding APIs
- modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.

I suppose it's possible to fold these features into the stock CodeArea, given sufficient interest from the community.



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

From pavelturk2000 at gmail.com  Tue Apr 29 21:06:04 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 30 Apr 2025 00:06:04 +0300
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <BYAPR10MB3013108DE93372E9EE05ACB3E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
 <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c264fd60-e311-4851-ae23-34ffc3e67368@gmail.com>
 <BYAPR10MB3013108DE93372E9EE05ACB3E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <c4b1e8bb-d940-4201-9a7a-21f0dd2fbbeb@gmail.com>

Yes, in JBS. I have no link. The system showed only ID - 9078447. The link comes when the issue? is approved.

Best regards, Pavel

On 4/30/25 00:02, Andy Goryachev wrote:
>
> In JBS?? What's the link?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Tuesday, April 29, 2025 at 13:56
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: RichTextArea: does CodeArea support code folding?
>
> I've just opened an issue about code folding.
>
> Best regards, Pavel
>
> On 4/29/25 22:52, Andy Goryachev wrote:
>
>     I do not disagree.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Tuesday, April 29, 2025 at 12:47
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: RichTextArea: does CodeArea support code folding?
>
>     I believe the community's interest in this feature can be demonstrated with three simple arguments:
>
>     1. The amount of code needed to implement what you described is comparable to the size of the existing CodeArea itself.
>     2. This feature already exists in RichTextFX (JavaFX) and RSyntaxTextArea (Swing).
>     3. It?s also present in editors like NetBeans, IntelliJ IDEA, and VS Code.
>
>     So, I think there?s every reason to add it to JFX CodeArea as well.
>
>     Best regards, Pavel
>
>     On 4/29/25 22:24, Andy Goryachev wrote:
>
>         Code folding is not currently supported by the CodeArea, at least with the models provided.
>
>         It might be possible to implement the folding in a custom component, using the following steps:
>
>         - implement a custom line number component which shows the folding decorations, knows how to get the actual line numbers, and how to handle the fold/unfold events
>
>         - implement a model that knows how to fold, and exposes the folding APIs
>
>         - modify the behavior of the CodeArea to deal with the folding as required: copy/paste, navigation, etc.
>
>         I suppose it's possible to /fold/ these features into the stock CodeArea, given sufficient interest from the community.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/41a8bd30/attachment.htm>

From philip.race at oracle.com  Tue Apr 29 21:16:23 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 29 Apr 2025 14:16:23 -0700
Subject: RichTextArea: does CodeArea support code folding?
In-Reply-To: <c4b1e8bb-d940-4201-9a7a-21f0dd2fbbeb@gmail.com>
References: <46132cfe-6942-4349-bd99-4ee66c91eedf@gmail.com>
 <BYAPR10MB301380129831C5C9CE0A3EE1E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <665d90dd-2f3c-4669-b254-1dbbebf502fe@gmail.com>
 <BYAPR10MB30132BDFB451AA5F73A891F8E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c264fd60-e311-4851-ae23-34ffc3e67368@gmail.com>
 <BYAPR10MB3013108DE93372E9EE05ACB3E5802@BYAPR10MB3013.namprd10.prod.outlook.com>
 <c4b1e8bb-d940-4201-9a7a-21f0dd2fbbeb@gmail.com>
Message-ID: <acb0aaf2-6b77-4f44-a102-34c5d1baf69f@oracle.com>

https://bugs.openjdk.org/browse/JDK-8355957

-phil.

On 4/29/25 2:06 PM, PavelTurk wrote:
> Yes, in JBS. I have no link. The system showed only ID - 9078447. The 
> link comes when the issue? is approved.
>
> Best regards, Pavel
>
> On 4/30/25 00:02, Andy Goryachev wrote:
>>
>> In JBS?? What's the link?
>>
>> -andy
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>> PavelTurk <pavelturk2000 at gmail.com>
>> *Date: *Tuesday, April 29, 2025 at 13:56
>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>> *Subject: *Re: RichTextArea: does CodeArea support code folding?
>>
>> I've just opened an issue about code folding.
>>
>> Best regards, Pavel
>>
>> On 4/29/25 22:52, Andy Goryachev wrote:
>>
>>     I do not disagree.
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk
>>     <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>>     *Date: *Tuesday, April 29, 2025 at 12:47
>>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>     <mailto:openjfx-dev at openjdk.org>
>>     *Subject: *Re: RichTextArea: does CodeArea support code folding?
>>
>>     I believe the community's interest in this feature can be
>>     demonstrated with three simple arguments:
>>
>>     1. The amount of code needed to implement what you described is
>>     comparable to the size of the existing CodeArea itself.
>>     2. This feature already exists in RichTextFX (JavaFX) and
>>     RSyntaxTextArea (Swing).
>>     3. It?s also present in editors like NetBeans, IntelliJ IDEA, and
>>     VS Code.
>>
>>     So, I think there?s every reason to add it to JFX CodeArea as well.
>>
>>     Best regards, Pavel
>>
>>     On 4/29/25 22:24, Andy Goryachev wrote:
>>
>>         Code folding is not currently supported by the CodeArea, at
>>         least with the models provided.
>>
>>         It might be possible to implement the folding in a custom
>>         component, using the following steps:
>>
>>         - implement a custom line number component which shows the
>>         folding decorations, knows how to get the actual line
>>         numbers, and how to handle the fold/unfold events
>>
>>         - implement a model that knows how to fold, and exposes the
>>         folding APIs
>>
>>         - modify the behavior of the CodeArea to deal with the
>>         folding as required: copy/paste, navigation, etc.
>>
>>         I suppose it's possible to /fold/ these features into the
>>         stock CodeArea, given sufficient interest from the community.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250429/9d47563a/attachment-0001.htm>

From mfox at openjdk.org  Wed Apr 30 03:38:34 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Apr 2025 03:38:34 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v3]
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Bumping up delay to ensure fullscreen transition is done on macOS

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1797/files
  - new: https://git.openjdk.org/jfx/pull/1797/files/54cc8a3f..2336af95

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

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

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

From pavelturk2000 at gmail.com  Wed Apr 30 11:14:27 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 30 Apr 2025 14:14:27 +0300
Subject: CodeArea: too frequent model updates
Message-ID: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>

Trying to understand why my Jfx CodeArea works so slowly I wrote a test application (see below).
And I got interesting results. If you start the application you will see that about 10 paragraphs
are visible.

1. If after start you click on the report button you will see that about 113 paragraphs were created (remember 10 visible).
2. If you click event button (as I understand to update only 15 paragraphs - I can be wrong here) in the report you will see 112 paragraphs.
3. If you scroll to line 100, click report to clear, add one letter via keyboard and in the new report you will see 210 paragraphs were updated.
So, with one paragraph modified and 10 paragraphs visible CodeArea updates 210 paragraphs.

I see two solutions here:
1) If Jfx CodeArea wants to update paragraphs itself it should be optimized
2) A better solution is to remove final modifier from CodeTextModel.getParagraph(int index) method so that we could override it.

public class JfxTextArea extends Application {

 ??? @Override
 ??? public void start(Stage primaryStage) throws Exception {
 ??????? CodeArea codeArea = new CodeArea();
 ??????? codeArea.setLineNumbersEnabled(true);
 ??????? final List<Integer> requestedIndexes = new ArrayList<>();
 ??????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
 ??????????? @Override
 ??????????? public RichParagraph createRichParagraph(CodeTextModel ctm, int i) {
 ??????????????? requestedIndexes.add(i);
 ??????????????? RichParagraph.Builder b = RichParagraph.builder();
 ??????????????? b.addSegment(ctm.getPlainText(i));
 ??????????????? return b.build();
 ??????????? }

 ??????????? @Override
 ??????????? public void handleChange(CodeTextModel ctm, TextPos tp, TextPos tp1, int i, int i1, int i2) {

 ??????????? }
 ??????? });
 ??????? StringBuilder sb = new StringBuilder();
 ??????? for (var i = 0; i < 1000; i++) {
 ??????????? sb.append(i);
 ??????????? sb.append("\n");
 ??????? }
 ??????? codeArea.setText(sb.toString());

 ??????? var reportButton = new Button("Report & Clear");
 ??????? reportButton.setOnAction(e -> {
 ??????????? Collections.sort(requestedIndexes);
 ??????????? System.out.println("Created/Updated " + requestedIndexes.size() + " paragraphs: " + requestedIndexes);
 ??????????? requestedIndexes.clear();
 ??????? });
 ??????? var topButton = new Button("To Top");
 ??????? topButton.setOnAction(e -> codeArea.select(new TextPos(0, 0, 0, true)));
 ??????? var bottomButton = new Button("To Bottom");
 ??????? bottomButton.setOnAction(e -> codeArea.select(new TextPos(999, 0, 0, true)));
 ??????? var eventButton = new Button("Fire Event");
 ??????? eventButton.setOnAction(e -> codeArea.getModel()
 ??????????????? .fireStyleChangeEvent(new TextPos(0, 0, 0, true), new TextPos(15, 0, 0, true)));
 ??????? HBox buttonBox = new HBox(reportButton, topButton, bottomButton, eventButton);

 ??????? VBox.setVgrow(codeArea, Priority.ALWAYS);
 ??????? VBox root = new VBox(codeArea, buttonBox);
 ??????? Scene scene = new Scene(root, 600, 200);
 ??????? primaryStage.setScene(scene);
 ??????? primaryStage.show();

 ??? }

 ??? public static void main(String[] args) {
 ??????? launch(args);
 ??? }

}

Best regards, Pavel

From mariushanl at web.de  Wed Apr 30 11:25:06 2025
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 30 Apr 2025 11:25:06 +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: <trinity-79f5a6d0-5673-425f-8f22-3db17f5e711e-1746012306111@trinity-msg-rest-webde-webde-live-bb6cbfdc7-hh85x>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/269881d5/attachment-0001.htm>

From angorya at openjdk.org  Wed Apr 30 14:29:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 14:29:53 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v3]
In-Reply-To: <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
Message-ID: <BD2zPRy3JfygEiiVDO9vxvZQAvv6y_FkGq3fo7szrPM=.5ae54cc3-2b68-47d8-b551-f744453940c9@github.com>

On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumping up delay to ensure fullscreen transition is done on macOS

lgtm, thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1797#pullrequestreview-2807268609

From andy.goryachev at oracle.com  Wed Apr 30 14:45:21 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Apr 2025 14:45:21 +0000
Subject: CodeArea: too frequent model updates
In-Reply-To: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>
References: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>
Message-ID: <BYAPR10MB30137F087189C32723C730ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>

Dear Pavel:

As I mentioned before, the view might request more paragraphs than currently visible, so it works as designed.

When you say it's slow, could you tell what metric / measurement you used?  The attached code does not appear slow on my macOS.  Would you provide a reproducer which can illustrate the issue?

Thanks
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 04:14
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: too frequent model updates
Trying to understand why my Jfx CodeArea works so slowly I wrote a test application (see below).
And I got interesting results. If you start the application you will see that about 10 paragraphs
are visible.

1. If after start you click on the report button you will see that about 113 paragraphs were created (remember 10 visible).
2. If you click event button (as I understand to update only 15 paragraphs - I can be wrong here) in the report you will see 112 paragraphs.
3. If you scroll to line 100, click report to clear, add one letter via keyboard and in the new report you will see 210 paragraphs were updated.
So, with one paragraph modified and 10 paragraphs visible CodeArea updates 210 paragraphs.

I see two solutions here:
1) If Jfx CodeArea wants to update paragraphs itself it should be optimized
2) A better solution is to remove final modifier from CodeTextModel.getParagraph(int index) method so that we could override it.

public class JfxTextArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         CodeArea codeArea = new CodeArea();
         codeArea.setLineNumbersEnabled(true);
         final List<Integer> requestedIndexes = new ArrayList<>();
         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel ctm, int i) {
                 requestedIndexes.add(i);
                 RichParagraph.Builder b = RichParagraph.builder();
                 b.addSegment(ctm.getPlainText(i));
                 return b.build();
             }

             @Override
             public void handleChange(CodeTextModel ctm, TextPos tp, TextPos tp1, int i, int i1, int i2) {

             }
         });
         StringBuilder sb = new StringBuilder();
         for (var i = 0; i < 1000; i++) {
             sb.append(i);
             sb.append("\n");
         }
         codeArea.setText(sb.toString());

         var reportButton = new Button("Report & Clear");
         reportButton.setOnAction(e -> {
             Collections.sort(requestedIndexes);
             System.out.println("Created/Updated " + requestedIndexes.size() + " paragraphs: " + requestedIndexes);
             requestedIndexes.clear();
         });
         var topButton = new Button("To Top");
         topButton.setOnAction(e -> codeArea.select(new TextPos(0, 0, 0, true)));
         var bottomButton = new Button("To Bottom");
         bottomButton.setOnAction(e -> codeArea.select(new TextPos(999, 0, 0, true)));
         var eventButton = new Button("Fire Event");
         eventButton.setOnAction(e -> codeArea.getModel()
                 .fireStyleChangeEvent(new TextPos(0, 0, 0, true), new TextPos(15, 0, 0, true)));
         HBox buttonBox = new HBox(reportButton, topButton, bottomButton, eventButton);

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         VBox root = new VBox(codeArea, buttonBox);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

     public static void main(String[] args) {
         launch(args);
     }

}

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/d575079c/attachment-0001.htm>

From angorya at openjdk.org  Wed Apr 30 15:13:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 15:13:00 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v3]
In-Reply-To: <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
Message-ID: <Mg-oyPltClFubIhxTzvH374EZMECdkNd3drhkpNILEE=.e2204890-be78-4739-bec0-d71604a60de7@github.com>

On Mon, 28 Apr 2025 09:38:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> With this change, you can now run the `swt` tests as easy as: `:swt:test -PSWT_TEST=true`.
>> ![image](https://github.com/user-attachments/assets/928141b5-ac81-4b15-9d86-5ea87f47c1c4)
>> 
>> Note: At one point `IS_FULL_TEST` was used as well for the enablement of the tests. I don't see any reason for it, and one flag seems to be enough to me. But open for opinions on this one.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SWT_TEST default is false on MacOS

- is this PR description still valid?
- there seems to be two GHA failures, are these intermittent or a result of the changes in this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2842317701

From kcr at openjdk.org  Wed Apr 30 15:23:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 30 Apr 2025 15:23:51 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v3]
In-Reply-To: <Mg-oyPltClFubIhxTzvH374EZMECdkNd3drhkpNILEE=.e2204890-be78-4739-bec0-d71604a60de7@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <0m1LQqk1pxv6tPsVdiSydeIgIZhIGLQ9yShb8hvz1m0=.6e704321-c4a0-4812-ac20-9e4d28cf148e@github.com>
 <Mg-oyPltClFubIhxTzvH374EZMECdkNd3drhkpNILEE=.e2204890-be78-4739-bec0-d71604a60de7@github.com>
Message-ID: <V1343kM9lMDWIPGhmEUSGNjznJnuX-ZctCdL-U1qoCs=.558e3cd5-abf0-46f5-94bb-4fe8090f484d@github.com>

On Wed, 30 Apr 2025 15:10:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> * is this PR description still valid?

Good catch. I think the PR Description should be updated.

> * there seems to be two GHA failures, are these intermittent or a result of the changes in this PR?

They are unrelated intermittent failures. He needs to push another update anyway, to fix or skip one of the tests on Linux as I noted above, so it will rerun then.

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2842358165

From sykora at openjdk.org  Wed Apr 30 15:30:56 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 30 Apr 2025 15:30:56 GMT
Subject: RFR: 8354875: Update to GCC 14.2.0 on Linux
In-Reply-To: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
References: <_9BM1G8x6BrlBsl9gNdPKi4cLxctoH3diLyGdG5lIVQ=.8b412a6c-9579-4964-aa09-e4ecabc773e6@github.com>
Message-ID: <O4OasT6emEQnDSDzX2drIF1sQpkOPqSRTeDwGjYtY6o=.22e029a8-802f-4826-9545-d4856e06cef3@github.com>

On Thu, 17 Apr 2025 18:17:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR updates the compiler on Linux to GCC 14.2.0 (from 13.2.0) to match JDK 25.
> 
> I ran a full headless and headful test run, including building media and WebKit, on the following:
> 
> * [x] Oracle Linux 8 (our production build and headless test platform)
> * [x] Ubuntu 16.04
> * [x] Ubuntu 22.04
> * [x] Ubuntu 24.04

I've updated our build infrastructure with gcc 14.2.0 and build and tests all ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1784#pullrequestreview-2807493887

From kizune at openjdk.org  Wed Apr 30 15:39:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 30 Apr 2025 15:39:55 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7waiVuGrZZ0lGzBMQGz9IWvduzJ6_74dM4A1tekRqik=.1a3ef4bb-ae42-474f-a768-aba3e240058c@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
 <7waiVuGrZZ0lGzBMQGz9IWvduzJ6_74dM4A1tekRqik=.1a3ef4bb-ae42-474f-a768-aba3e240058c@github.com>
Message-ID: <kKYOOp7qktW4pS5CsiRoUe128tiYgJNaQPMcUsu76m4=.44cbdf6b-cd1c-46af-bc77-5d339cd89a53@github.com>

On Mon, 28 Apr 2025 21:25:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Are these changes testable? If so, could you please describe what we are supposed to see during the testing?

This fix covers two controls - ProgressBar and ProgressIndicator, i used Ensemble, it has pages for both with values and just "Busy" so navigating these components with the a11y shortcut keys you should be able to put the a11y cursor on them to read the type and value of each. Unfortunately mac does not have separate a11y representation for progress bar so in both cases voiceover should read "Busy Progress Indicator" for the busy progress bar and progress indicator and "Progress Indicator, x%" for the rest. The behavior should be the same for old and new implementation although i am thinking on enhancing it - for example the indicator that is completed and has "Done" set as a label i want to add that label to the VO output so it reads "Progress indicator, 100%, Done" or something like it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2842410861

From pavelturk2000 at gmail.com  Wed Apr 30 15:53:23 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 30 Apr 2025 18:53:23 +0300
Subject: CodeArea: too frequent model updates
In-Reply-To: <BYAPR10MB30137F087189C32723C730ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>
 <BYAPR10MB30137F087189C32723C730ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <38578b75-de24-4a89-936d-5b92fbbe0a02@gmail.com>

Hello, Andy

I've made sure to formulate everything very precisely and just created a new issue. Unfortunately I know only its ID: 9078451.

If my proposal is incorrect - then this issue is not meant to be resolved. However, I'm certain this is an important question regardless.

Best regards, Pavel

On 4/30/25 17:45, Andy Goryachev wrote:
>
> Dear Pavel:
>
> As I mentioned before, the view might request more paragraphs than currently visible, so it works as designed.
>
> When you say it's slow, could you tell what metric / measurement you used?? The attached code does not appear slow on my macOS.? Would you provide a reproducer which can illustrate the issue?
>
> Thanks
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, April 30, 2025 at 04:14
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *CodeArea: too frequent model updates
>
> Trying to understand why my Jfx CodeArea works so slowly I wrote a test application (see below).
> And I got interesting results. If you start the application you will see that about 10 paragraphs
> are visible.
>
> 1. If after start you click on the report button you will see that about 113 paragraphs were created (remember 10 visible).
> 2. If you click event button (as I understand to update only 15 paragraphs - I can be wrong here) in the report you will see 112 paragraphs.
> 3. If you scroll to line 100, click report to clear, add one letter via keyboard and in the new report you will see 210 paragraphs were updated.
> So, with one paragraph modified and 10 paragraphs visible CodeArea updates 210 paragraphs.
>
> I see two solutions here:
> 1) If Jfx CodeArea wants to update paragraphs itself it should be optimized
> 2) A better solution is to remove final modifier from CodeTextModel.getParagraph(int index) method so that we could override it.
>
> public class JfxTextArea extends Application {
>
> ???? @Override
> ???? public void start(Stage primaryStage) throws Exception {
> ???????? CodeArea codeArea = new CodeArea();
> ???????? codeArea.setLineNumbersEnabled(true);
> ???????? final List<Integer> requestedIndexes = new ArrayList<>();
> ???????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
> ???????????? @Override
> ???????????? public RichParagraph createRichParagraph(CodeTextModel ctm, int i) {
> ???????????????? requestedIndexes.add(i);
> ???????????????? RichParagraph.Builder b = RichParagraph.builder();
> ???????????????? b.addSegment(ctm.getPlainText(i));
> ???????????????? return b.build();
> ???????????? }
>
> ???????????? @Override
> ???????????? public void handleChange(CodeTextModel ctm, TextPos tp, TextPos tp1, int i, int i1, int i2) {
>
> ???????????? }
> ???????? });
> ???????? StringBuilder sb = new StringBuilder();
> ???????? for (var i = 0; i < 1000; i++) {
> ???????????? sb.append(i);
> ???????????? sb.append("\n");
> ???????? }
> ???????? codeArea.setText(sb.toString());
>
> ???????? var reportButton = new Button("Report & Clear");
> ???????? reportButton.setOnAction(e -> {
> ???????????? Collections.sort(requestedIndexes);
> ???????????? System.out.println("Created/Updated " + requestedIndexes.size() + " paragraphs: " + requestedIndexes);
> ???????????? requestedIndexes.clear();
> ???????? });
> ???????? var topButton = new Button("To Top");
> ???????? topButton.setOnAction(e -> codeArea.select(new TextPos(0, 0, 0, true)));
> ???????? var bottomButton = new Button("To Bottom");
> ???????? bottomButton.setOnAction(e -> codeArea.select(new TextPos(999, 0, 0, true)));
> ???????? var eventButton = new Button("Fire Event");
> ???????? eventButton.setOnAction(e -> codeArea.getModel()
> ???????????????? .fireStyleChangeEvent(new TextPos(0, 0, 0, true), new TextPos(15, 0, 0, true)));
> ???????? HBox buttonBox = new HBox(reportButton, topButton, bottomButton, eventButton);
>
> ???????? VBox.setVgrow(codeArea, Priority.ALWAYS);
> ???????? VBox root = new VBox(codeArea, buttonBox);
> ???????? Scene scene = new Scene(root, 600, 200);
> ???????? primaryStage.setScene(scene);
> ???????? primaryStage.show();
>
> ???? }
>
> ???? public static void main(String[] args) {
> ???????? launch(args);
> ???? }
>
> }
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/3dcc0896/attachment.htm>

From andy.goryachev at oracle.com  Wed Apr 30 16:05:56 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Apr 2025 16:05:56 +0000
Subject: CodeArea: too frequent model updates
In-Reply-To: <38578b75-de24-4a89-936d-5b92fbbe0a02@gmail.com>
References: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>
 <BYAPR10MB30137F087189C32723C730ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
 <38578b75-de24-4a89-936d-5b92fbbe0a02@gmail.com>
Message-ID: <BYAPR10MB301399E62AF7F3CC780E57ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you, Pavel, for filing the ticket (it will take some time before it gets routed to me).  And thank you so much for the feedback - keep it going!

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 08:54
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: too frequent model updates
Hello, Andy

I've made sure to formulate everything very precisely and just created a new issue. Unfortunately I know only its ID: 9078451.

If my proposal is incorrect - then this issue is not meant to be resolved. However, I'm certain this is an important question regardless.

Best regards, Pavel
On 4/30/25 17:45, Andy Goryachev wrote:
Dear Pavel:

As I mentioned before, the view might request more paragraphs than currently visible, so it works as designed.

When you say it's slow, could you tell what metric / measurement you used?  The attached code does not appear slow on my macOS.  Would you provide a reproducer which can illustrate the issue?

Thanks
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 04:14
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: too frequent model updates
Trying to understand why my Jfx CodeArea works so slowly I wrote a test application (see below).
And I got interesting results. If you start the application you will see that about 10 paragraphs
are visible.

1. If after start you click on the report button you will see that about 113 paragraphs were created (remember 10 visible).
2. If you click event button (as I understand to update only 15 paragraphs - I can be wrong here) in the report you will see 112 paragraphs.
3. If you scroll to line 100, click report to clear, add one letter via keyboard and in the new report you will see 210 paragraphs were updated.
So, with one paragraph modified and 10 paragraphs visible CodeArea updates 210 paragraphs.

I see two solutions here:
1) If Jfx CodeArea wants to update paragraphs itself it should be optimized
2) A better solution is to remove final modifier from CodeTextModel.getParagraph(int index) method so that we could override it.

public class JfxTextArea extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         CodeArea codeArea = new CodeArea();
         codeArea.setLineNumbersEnabled(true);
         final List<Integer> requestedIndexes = new ArrayList<>();
         codeArea.setSyntaxDecorator(new SyntaxDecorator() {
             @Override
             public RichParagraph createRichParagraph(CodeTextModel ctm, int i) {
                 requestedIndexes.add(i);
                 RichParagraph.Builder b = RichParagraph.builder();
                 b.addSegment(ctm.getPlainText(i));
                 return b.build();
             }

             @Override
             public void handleChange(CodeTextModel ctm, TextPos tp, TextPos tp1, int i, int i1, int i2) {

             }
         });
         StringBuilder sb = new StringBuilder();
         for (var i = 0; i < 1000; i++) {
             sb.append(i);
             sb.append("\n");
         }
         codeArea.setText(sb.toString());

         var reportButton = new Button("Report & Clear");
         reportButton.setOnAction(e -> {
             Collections.sort(requestedIndexes);
             System.out.println("Created/Updated " + requestedIndexes.size() + " paragraphs: " + requestedIndexes);
             requestedIndexes.clear();
         });
         var topButton = new Button("To Top");
         topButton.setOnAction(e -> codeArea.select(new TextPos(0, 0, 0, true)));
         var bottomButton = new Button("To Bottom");
         bottomButton.setOnAction(e -> codeArea.select(new TextPos(999, 0, 0, true)));
         var eventButton = new Button("Fire Event");
         eventButton.setOnAction(e -> codeArea.getModel()
                 .fireStyleChangeEvent(new TextPos(0, 0, 0, true), new TextPos(15, 0, 0, true)));
         HBox buttonBox = new HBox(reportButton, topButton, bottomButton, eventButton);

         VBox.setVgrow(codeArea, Priority.ALWAYS);
         VBox root = new VBox(codeArea, buttonBox);
         Scene scene = new Scene(root, 600, 200);
         primaryStage.setScene(scene);
         primaryStage.show();

     }

     public static void main(String[] args) {
         launch(args);
     }

}

Best regards, Pavel

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

From kevin.rushforth at oracle.com  Wed Apr 30 16:22:14 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 30 Apr 2025 09:22:14 -0700
Subject: CodeArea: too frequent model updates
In-Reply-To: <BYAPR10MB301399E62AF7F3CC780E57ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <af081d6e-2e46-4261-9e4d-49199e1911ae@gmail.com>
 <BYAPR10MB30137F087189C32723C730ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
 <38578b75-de24-4a89-936d-5b92fbbe0a02@gmail.com>
 <BYAPR10MB301399E62AF7F3CC780E57ACE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <9a41a7b7-dc3b-451d-a97c-0f157b954a7c@oracle.com>

https://bugs.openjdk.org/browse/JDK-8355986

On 4/30/2025 9:05 AM, Andy Goryachev wrote:
>
> Thank you, Pavel, for filing the ticket (it will take some time before 
> it gets routed to me).? And thank you so much for the feedback - keep 
> it going!
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, April 30, 2025 at 08:54
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: CodeArea: too frequent model updates
>
> Hello, Andy
>
> I've made sure to formulate everything very precisely and just created 
> a new issue. Unfortunately I know only its ID: 9078451.
>
> If my proposal is incorrect - then this issue is not meant to be 
> resolved. However, I'm certain this is an important question regardless.
>
> Best regards, Pavel
>
> On 4/30/25 17:45, Andy Goryachev wrote:
>
>     Dear Pavel:
>
>     As I mentioned before, the view might request more paragraphs than
>     currently visible, so it works as designed.
>
>     When you say it's slow, could you tell what metric / measurement
>     you used?? The attached code does not appear slow on my macOS.?
>     Would you provide a reproducer which can illustrate the issue?
>
>     Thanks
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk
>     <pavelturk2000 at gmail.com> <mailto:pavelturk2000 at gmail.com>
>     *Date: *Wednesday, April 30, 2025 at 04:14
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *CodeArea: too frequent model updates
>
>     Trying to understand why my Jfx CodeArea works so slowly I wrote a
>     test application (see below).
>     And I got interesting results. If you start the application you
>     will see that about 10 paragraphs
>     are visible.
>
>     1. If after start you click on the report button you will see that
>     about 113 paragraphs were created (remember 10 visible).
>     2. If you click event button (as I understand to update only 15
>     paragraphs - I can be wrong here) in the report you will see 112
>     paragraphs.
>     3. If you scroll to line 100, click report to clear, add one
>     letter via keyboard and in the new report you will see 210
>     paragraphs were updated.
>     So, with one paragraph modified and 10 paragraphs visible CodeArea
>     updates 210 paragraphs.
>
>     I see two solutions here:
>     1) If Jfx CodeArea wants to update paragraphs itself it should be
>     optimized
>     2) A better solution is to remove final modifier from
>     CodeTextModel.getParagraph(int index) method so that we could
>     override it.
>
>     public class JfxTextArea extends Application {
>
>     ???? @Override
>     ???? public void start(Stage primaryStage) throws Exception {
>     ???????? CodeArea codeArea = new CodeArea();
>     codeArea.setLineNumbersEnabled(true);
>     ???????? final List<Integer> requestedIndexes = new ArrayList<>();
>     ???????? codeArea.setSyntaxDecorator(new SyntaxDecorator() {
>     ???????????? @Override
>     ???????????? public RichParagraph
>     createRichParagraph(CodeTextModel ctm, int i) {
>     ???????????????? requestedIndexes.add(i);
>     ???????????????? RichParagraph.Builder b = RichParagraph.builder();
>     b.addSegment(ctm.getPlainText(i));
>     ???????????????? return b.build();
>     ???????????? }
>
>     ???????????? @Override
>     ???????????? public void handleChange(CodeTextModel ctm, TextPos
>     tp, TextPos tp1, int i, int i1, int i2) {
>
>     ???????????? }
>     ???????? });
>     ???????? StringBuilder sb = new StringBuilder();
>     ???????? for (var i = 0; i < 1000; i++) {
>     ???????????? sb.append(i);
>     ???????????? sb.append("\n");
>     ???????? }
>     ???????? codeArea.setText(sb.toString());
>
>     ???????? var reportButton = new Button("Report & Clear");
>     ???????? reportButton.setOnAction(e -> {
>     Collections.sort(requestedIndexes);
>     System.out.println("Created/Updated " + requestedIndexes.size() +
>     " paragraphs: " + requestedIndexes);
>     ???????????? requestedIndexes.clear();
>     ???????? });
>     ???????? var topButton = new Button("To Top");
>     ???????? topButton.setOnAction(e -> codeArea.select(new TextPos(0,
>     0, 0, true)));
>     ???????? var bottomButton = new Button("To Bottom");
>     ???????? bottomButton.setOnAction(e -> codeArea.select(new
>     TextPos(999, 0, 0, true)));
>     ???????? var eventButton = new Button("Fire Event");
>     ???????? eventButton.setOnAction(e -> codeArea.getModel()
>     ???????????????? .fireStyleChangeEvent(new TextPos(0, 0, 0, true),
>     new TextPos(15, 0, 0, true)));
>     ???????? HBox buttonBox = new HBox(reportButton, topButton,
>     bottomButton, eventButton);
>
>     ???????? VBox.setVgrow(codeArea, Priority.ALWAYS);
>     ???????? VBox root = new VBox(codeArea, buttonBox);
>     ???????? Scene scene = new Scene(root, 600, 200);
>     ???????? primaryStage.setScene(scene);
>     ???????? primaryStage.show();
>
>     ???? }
>
>     ???? public static void main(String[] args) {
>     ???????? launch(args);
>     ???? }
>
>     }
>
>     Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/8c72ce69/attachment-0001.htm>

From mfox at openjdk.org  Wed Apr 30 17:56:05 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Apr 2025 17:56:05 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
Message-ID: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>

macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.

The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.

System tests for this case are underway as part of PR #1789.

You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

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

Commit messages:
 - Replaced deprecated style mask constants
 - Removed incorrect cast and unnecessary check

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

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

From angorya at openjdk.org  Wed Apr 30 18:03:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 18:03:54 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <_K0IfVGlOjP6DiXybzSov4_b8NzCyG60gmBB78uz6y8=.422568dd-8864-47ba-8d0f-e60912cc6cda@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

Thank you for taking on this issue!

Does this PR depend on https://github.com/openjdk/jfx/pull/1789 in any way (system tests?).  In other words, should we wait for 1789 before looking at this, or this PR is sufficiently independent?

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

PR Comment: https://git.openjdk.org/jfx/pull/1799#issuecomment-2842861107

From mfox at openjdk.org  Wed Apr 30 19:08:51 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Apr 2025 19:08:51 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <-Xw0TZrmcixtnHqyNkOKUM9OKh8gu9aMOO4z2ILS7IA=.1b8c1776-1517-47a2-8e81-70be17a32ceb@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

> Does this PR depend on #1789 in any way (system tests?). In other words, should we wait for 1789 before looking at this, or this PR is sufficiently independent?

This is a small enough PR that I was hoping to get it in before #1789 which might take a while to go through. Still, it needs to be tested with all of the different stage styles and #1789 has all the system tests for that. I've been testing it using a manual test app, the one I attached to [JDK-8355990](https://bugs.openjdk.org/browse/JDK-8355990). #1789 also has a manual test case you can grab (it's called TestStage.java). Let me know if you want one of these attached here or to the JBS ticket.

Never sure how to deal with this chicken-and-egg problem. I've been trying to get fixes in before the tests in #1789 are submitted since that seems less complicated than disabling the tests in that PR and then having to go back and re-enable them piecemeal later.

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

PR Comment: https://git.openjdk.org/jfx/pull/1799#issuecomment-2843010679

From angorya at openjdk.org  Wed Apr 30 19:19:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 19:19:57 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <b0jWaALpRRG9kXlXSZdydzoh-1VRM8y1DxWF-Htdh-o=.11c6f870-3ed6-4d58-a037-0bc4cb1657a8@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

I see, thanks.
We can try to process this independently of #1789, since we do have a reproducer in the ticket.

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

PR Comment: https://git.openjdk.org/jfx/pull/1799#issuecomment-2843035524

From kcr at openjdk.org  Wed Apr 30 20:27:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 30 Apr 2025 20:27:57 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v3]
In-Reply-To: <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
Message-ID: <Kq6VKi2g3921kUGsYUt1xh96xIjsHBrMQawzeyv8OhQ=.2abe3602-da1a-4556-b5d1-43e2b8ca9640@github.com>

On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumping up delay to ensure fullscreen transition is done on macOS

I'm doing a headful test run on our CI system with this PR + PR #1799 (so I don't have to do two runs). I'll also review it later.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2843200833

From kcr at openjdk.org  Wed Apr 30 20:28:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 30 Apr 2025 20:28:52 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <veq2s-kZJOhNVhBTHpdz2nph3zrXc43K2u395Oig1DE=.cdcaa5c7-5fe5-41ac-8da4-f8e236cf4b09@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

The code changes look good. I'm doing a headful test run on our CI system with this PR + PR #1797 (so I don't have to do two runs). I'll finish my review later.

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

PR Comment: https://git.openjdk.org/jfx/pull/1799#issuecomment-2843202245

From angorya at openjdk.org  Wed Apr 30 20:44:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 20:44:54 GMT
Subject: RFR: 8353314: macOS: Inconsistent fullscreen behavior
In-Reply-To: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
References: <CrDAFODL84CnPveThQA9CxXEEq-Q6FoOU8u_VHp96-c=.600d0f61-7da0-422a-bf5c-7fa183731f4c@github.com>
Message-ID: <AJ7iVxRwCoaX5kKALrZZEAqO6iQYWY7fiLVDcxumBGA=.33294ed5-7551-49be-a93e-936d92108d92@github.com>

On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS will allow any window to enter fullscreen mode but won't expand the window's size if the resizable bit isn't set in the window's style mask. For undecorated stages the code has to set this bit before entering fullscreen and restore the old value after exiting fullscreen.
> 
> The old code was taking a pointer to an NSWindow and casting it to a pointer to an unrelated type (GlassWindow). It was also making an unnecessary check. windowWillEnterFullScreen stashes away the state of the resizable bit before setting it and windowDidExitFullScreen restores the old state. There's no need for setResizableForFullscreen to check anything, it just needs to do what it's told.
> 
> System tests for this case are underway as part of PR #1789.
> 
> You might have difficulty reproducing the bug in the master branch.  The old code was doing a bogus pointer cast and then dereferencing it to check a state flag so the code sometimes worked and sometimes didn't.

Oh yes, the reproducer works as expected on macOS M1 15.4.1:


scene.width=150.0
scene.height=17.0
stage.width=150.0
stage.height=17.0
scene.width=1800.0
scene.height=1126.0
stage.width=1800.0
stage.height=1126.0
scene.width=150.0
scene.height=17.0
stage.width=150.0
stage.height=17.0


no ill effects observed in the monkey tester transitioning to/from fullscreen with iconified / maximized / normal / on top flags.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1799#pullrequestreview-2808392900

From angorya at openjdk.org  Wed Apr 30 21:05:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 21:05:52 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <ZDm33BW6eRaNKeWFobMxY_2Q6s5-Ugq-zICmrfnXKOY=.ad1db392-1ee1-4845-8288-2078a2e3f9a0@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

I've added a missing ProgressBar page to the monkey tester:
https://github.com/andy-goryachev-oracle/MonkeyTest

I can't tell the difference using VoiceOver while testing with and without the fix.  It announces "progress indicator", busy or N percent, as expected - in both cases.

In the monkey tester, one can use Logging -> Accessibility menu to enable accessibility logging (I don't see much of a difference, but there is a lot of noise).

Does it mean the code works as expected?

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2843276385

From angorya at openjdk.org  Wed Apr 30 21:09:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 21:09:51 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <1BTzWWe2rUGw6keT6xZbMJRCRQkbHkVMgUdwqRA3fsE=.0775764f-d16a-49d8-ba11-fd3c9ae82fe9@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

it does announce the value of the `accessibleText` property when set.

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2843284645

From pavelturk2000 at gmail.com  Wed Apr 30 21:19:08 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 1 May 2025 00:19:08 +0300
Subject: CodeArea: are tab lines supported?
Message-ID: <38e43fb8-24b5-4bef-af70-d9feeb7608d6@gmail.com>

Does CodeArea support tab lines (see this link <https://ibb.co/qM7CCg40>)? If not I will open an issue.

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250501/487a886f/attachment.htm>

From andy.goryachev at oracle.com  Wed Apr 30 21:22:26 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Apr 2025 21:22:26 +0000
Subject: CodeArea: are tab lines supported?
In-Reply-To: <38e43fb8-24b5-4bef-af70-d9feeb7608d6@gmail.com>
References: <38e43fb8-24b5-4bef-af70-d9feeb7608d6@gmail.com>
Message-ID: <BYAPR10MB3013069F2326D1671014781DE5832@BYAPR10MB3013.namprd10.prod.outlook.com>

CodeArea does not support tab lines.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 14:19
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: CodeArea: are tab lines supported?
Does CodeArea support tab lines (see this link<https://ibb.co/qM7CCg40>)? If not I will open an issue.

Best regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250430/9a299c9d/attachment-0001.htm>

From pavelturk2000 at gmail.com  Wed Apr 30 21:32:04 2025
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 1 May 2025 00:32:04 +0300
Subject: CodeArea: are tab lines supported?
In-Reply-To: <BYAPR10MB3013069F2326D1671014781DE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <38e43fb8-24b5-4bef-af70-d9feeb7608d6@gmail.com>
 <BYAPR10MB3013069F2326D1671014781DE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <8b6d31e0-ef0e-4bc5-b11c-27070efc92d2@gmail.com>

Ok, I've just opened a new issue, id: 9078453

Best regards, Pavel

On 5/1/25 00:22, Andy Goryachev wrote:
>
> CodeArea does not support tab lines.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
> *Date: *Wednesday, April 30, 2025 at 14:19
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *CodeArea: are tab lines supported?
>
> Does CodeArea support tab lines (see this link <https://ibb.co/qM7CCg40>)? If not I will open an issue.
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250501/dbd07e5a/attachment.htm>

From kcr at openjdk.org  Wed Apr 30 21:28:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 30 Apr 2025 21:28:52 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v3]
In-Reply-To: <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
Message-ID: <6EQVxiCMvgbdMGbiQDn66cTXNuEPt7D92gXkUggQo7M=.2ece95ca-1046-4df0-a80c-74065328a7f1@github.com>

On Wed, 30 Apr 2025 03:38:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
>> 
>> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
>> 
>> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bumping up delay to ensure fullscreen transition is done on macOS

During the headful test run, the following test failed on all four of our test systems, so it is likely related to your fix.


RestoreStagePositionTest > testDemaximizedPosition() FAILED
    org.opentest4j.AssertionFailedError: Window was moved ==> expected: <400.0> but was: <424.0>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:86)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1024)
        at app//test.javafx.stage.RestoreStagePositionTest.testDemaximizedPosition(RestoreStagePositionTest.java:152)


I note that the x64 systems had a different actual value (450), which is probably related to screen resolution or visible bounds of the system.

This was on the maximize / demaximize test. There is a full screen test in the same test class.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2843322511

From andy.goryachev at oracle.com  Wed Apr 30 21:50:20 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Apr 2025 21:50:20 +0000
Subject: CodeArea: are tab lines supported?
In-Reply-To: <8b6d31e0-ef0e-4bc5-b11c-27070efc92d2@gmail.com>
References: <38e43fb8-24b5-4bef-af70-d9feeb7608d6@gmail.com>
 <BYAPR10MB3013069F2326D1671014781DE5832@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8b6d31e0-ef0e-4bc5-b11c-27070efc92d2@gmail.com>
Message-ID: <BYAPR10MB3013B51CC87A4F1DDA533645E5832@BYAPR10MB3013.namprd10.prod.outlook.com>

https://bugs.openjdk.org/browse/JDK-8356019


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 14:32
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: CodeArea: are tab lines supported?
Ok, I've just opened a new issue, id: 9078453

Best regards, Pavel
On 5/1/25 00:22, Andy Goryachev wrote:
CodeArea does not support tab lines.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of PavelTurk <pavelturk2000 at gmail.com><mailto:pavelturk2000 at gmail.com>
Date: Wednesday, April 30, 2025 at 14:19
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: CodeArea: are tab lines supported?
Does CodeArea support tab lines (see this link<https://ibb.co/qM7CCg40>)? If not I will open an issue.

Best regards, Pavel

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

From angorya at openjdk.org  Wed Apr 30 21:54:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Apr 2025 21:54:49 GMT
Subject: RFR: 8350316: Create implementation of
 NSAccessibilityProgressIndicator protocol
In-Reply-To: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
References: <7jZARDYnTPzJwHVwFRiyT6S9fAlltnZnEcluDtmVJiw=.17dd3196-0f1d-46ee-aab9-ad661ee468e3@github.com>
Message-ID: <ByLpR0uY5VBtBescqrJ4XWqj4p6JByWDISjNoqPg4MY=.63cc4b99-5e74-40da-8459-05496bded86a@github.com>

On Mon, 28 Apr 2025 04:37:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. In order to implement progress indicator the group accessibility protocol has to be implemented too so this is also a fix for 8351773. There are commented out sections that can be used to verify the functionality of the code since it has to behave exactly in the same way as the code without the fix. After review is done i will remove the debug output.

How can one test the group protocol change?

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

PR Comment: https://git.openjdk.org/jfx/pull/1796#issuecomment-2843397759

From mhanl at openjdk.org  Wed Apr 30 21:55:51 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 30 Apr 2025 21:55:51 GMT
Subject: RFR: 8169285: Re-enable javafx.swt tests [v2]
In-Reply-To: <dWWdm42_W2BakDJ1psKgrHweCi4ORNejV2j5yu_H-dU=.21758034-390c-4709-aed2-a8f8749d3884@github.com>
References: <QC5Pmg-pTlnxsw5bp1Gf2AwaXB9cV2hRR1GUwLv0EqU=.bea33b59-ab7a-4ab3-8e05-3eff6968d7f4@github.com>
 <WZ5xMCzORkrUA0lVdcHQaORNEL8yBbC8ui0772ENmTc=.22b67b3f-0ad1-403f-92bb-b62dd8c5c23e@github.com>
 <dWWdm42_W2BakDJ1psKgrHweCi4ORNejV2j5yu_H-dU=.21758034-390c-4709-aed2-a8f8749d3884@github.com>
Message-ID: <xK-TpgHp9PGYGpwMiZ3Q2LPT4UJvv4_cXoxW7bomUmE=.a9363977-799d-4e33-9f86-63fecdbcb409@github.com>

On Thu, 24 Apr 2025 16:55:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I confirm that this runs fine on my Windows 11 system.
> 
> @Maran23 what platforms did you test this on? Windows?
> 
> I fired off a CI headful test run, and I see the following failure on Ubuntu 22.04:

I setup an Ubuntu 24.04.2 LTS inside WSL, did `export GDK_BACKEND=x11` (otherwise I always got a crash).
The tests are always green for me. Tried several times.
![image](https://github.com/user-attachments/assets/41e0d22d-40e9-4c98-ab4f-f61d9891155d)

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

PR Comment: https://git.openjdk.org/jfx/pull/1783#issuecomment-2843406703

From mfox at openjdk.org  Wed Apr 30 23:34:06 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Apr 2025 23:34:06 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v4]
In-Reply-To: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
Message-ID: <zjfp_N3x7NAof47TPt6nxIvL0Bt6UuHcAjICflv80f4=.8a845bac-c09a-40b1-af6e-8b94d7254672@github.com>

> On macOS the system animates the transition into and out of fullscreen and this animation runs asynchronously. JavaFX tries to make the setFullScreen call appear synchronous by running a nested event loop while the transition is going on. But this means that runLater runnables can fire during a call to setFullScreen.
> 
> This can also occur during a call to Window.hide() if the window is in fullscreen mode. During the setView call glass tries to take the window out of fullscreen mode which fires up a nested event loop and, again, runLater runnables (like pulses) start firing.
> 
> In this PR GlassRunnables that try to run during the fullscreen transition are instead placed in a deferral list. When the fullscreen event loop exits they are re-scheduled.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Disabling testDemaximizedPosition (again). Seems to be failing on some test machines.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1797/files
  - new: https://git.openjdk.org/jfx/pull/1797/files/2336af95..6aecb598

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

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

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

From mfox at openjdk.org  Wed Apr 30 23:46:49 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Apr 2025 23:46:49 GMT
Subject: RFR: 8176813: Mac: Failure to exit full-screen programmatically in
 some cases [v3]
In-Reply-To: <6EQVxiCMvgbdMGbiQDn66cTXNuEPt7D92gXkUggQo7M=.2ece95ca-1046-4df0-a80c-74065328a7f1@github.com>
References: <XEQsz0gxfEbjOEg4z6C8m6la-5Y-Jin60opecB_zvns=.fc7e2e3a-bbe4-497d-b68e-64ba38441e55@github.com>
 <FOM9REwtSfrx9nlwZvnzotNR3WomoXenbFnQA_ER5EE=.f2bd569c-d676-4917-bd19-6855555255d0@github.com>
 <6EQVxiCMvgbdMGbiQDn66cTXNuEPt7D92gXkUggQo7M=.2ece95ca-1046-4df0-a80c-74065328a7f1@github.com>
Message-ID: <3iNhrnW70_GTBkSUohlnJZc5TYXoWAe7bbaYJl5TQXo=.a0f51404-ee18-4157-b70c-3892ba5dd1d7@github.com>

On Wed, 30 Apr 2025 21:26:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> During the headful test run, the following test failed on all four of our test systems, so it is likely related to your fix.

I think it's unrelated. During testing @andy-goryachev-oracle noted that the demaximized position test was no longer failing. According to the JBS the issue that was blocking that test was fixed years ago. So I (foolishly) re-enabled it and verified that it worked fine on my system (and apparently the system @andy-goryachev-oracle is using).

I've disabled it again. I should not have enabled it since it's irrelevant to the original bug or the changes in this PR. Sorry about that.

Still, it's puzzling that this is failing on the test systems. It's maximizing a 300x400 stage and then de-maximizing it. That should work unless the screen is tiny. I've been looking at the maximization code and it can get the size of the window wrong but it shouldn't get the x,y position wrong. I'll take a closer look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1797#issuecomment-2843742284