From nlisker at openjdk.org  Mon Sep  1 21:18:49 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 1 Sep 2025 21:18:49 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: <uGEL78oU9Jg8IBSaiaTI_a4wax7jGn3-JcAheGG13hk=.df463067-6b73-4b83-bf86-88a54ba05273@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <JDNM00uDD8EoKJuuz5qIPjH7OXZTts_lPM-bYSzqDCc=.3d393ad6-37fa-4a34-bfaa-3b4f328d7176@github.com>
 <zZD0IJ_U9IL3KaWyqEKFBPZ4KlNwLnlj8My5u7AZTRo=.a1b7b8e2-e54e-49d1-b214-12b55599c6b2@github.com>
 <sJRFcZGoKaTuUDeUtcA1Nc1CXQH54yW9uuye4JXQaZo=.d27dea3f-4ede-4839-a8b2-489923f2b139@github.com>
 <v5suJvAPCpIMEiCZCHwLd5RsqXfWfGQk_Gy2EeUiheU=.85e1fc20-824a-4385-97bd-6b8425e7fb37@github.com>
 <uGEL78oU9Jg8IBSaiaTI_a4wax7jGn3-JcAheGG13hk=.df463067-6b73-4b83-bf86-88a54ba05273@github.com>
Message-ID: <7G8Rb7FfNKqLDb8Bz1-dfGtIgOSbkkEfL2aJOWK0ffM=.8ead616b-9b51-4750-b42f-5fa294ad78ef@github.com>

On Fri, 29 Aug 2025 22:19:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Eclipse does not refresh its javadoc pane with markdown as it does with the usual style

Was fixed months ago in https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/2051. Not sure if a stable version was released yet.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2314576417

From angorya at openjdk.org  Tue Sep  2 15:30:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Sep 2025 15:30:57 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v4]
In-Reply-To: <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
Message-ID: <L6MbpiHbaMEk0gMYWaUtzetaDsCGU5YIfxDId9BIVO0=.f0b5c515-1707-4e6e-8dc8-a5e198ab3c88@github.com>

On Sat, 30 Aug 2025 22:07:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> Michael Strau? 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/1822#pullrequestreview-3177085063

From mfox at openjdk.org  Tue Sep  2 15:31:06 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 2 Sep 2025 15:31:06 GMT
Subject: RFR: 8366568: Allow replacing built in application menu in system menu
 bar
Message-ID: <bvW8so_fpqLcJ8MlTeht41leQ0mnot605eArY2DkRtk=.3eebc5bb-f923-4499-a2e7-b83aef11cdad@github.com>

This PR provides an API for replacing the application menu that JavaFX places in the system menu bar on macOS. The application menu is the one next to the Apple menu that is titled with the application's name and contains the Quit menu item. The JavaFX version of this menu has many limitations so this PR allows a developer to simply replace it outright.

Technically there?s no reason to restrict this to only one menu so the API allows the developer to specify an observable list of Menus known as the common system menus. Like the current application menu the common menus are present for all JavaFX windows and remain present even if all windows lose focus. Any per-window menus provided by a MenuBar with useSystemMenuBar set will appear alongside the common system menus.

In addition the PR provides some calls that allow a developer to implement the Hide <app name>, Hide Others, and Show All menu items that are expected in the application menu.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into commonmenus
 - Specify a list of menus that are always present in the system menu bar

Changes: https://git.openjdk.org/jfx/pull/1881/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366568
  Stats: 586 lines in 12 files changed: 560 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1881.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1881/head:pull/1881

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

From martinfox656 at gmail.com  Tue Sep  2 15:33:50 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Tue, 2 Sep 2025 08:33:50 -0700
Subject: Proposing an API for replacing the application menu on macOS
Message-ID: <31E81814-652D-4741-9E0B-F89B6D5A90C3@gmail.com>

I?ve submitted a draft PR (#1881) with an API that allows a JavaFX developer to replace the application menu on macOS. This is the first menu in the system menu bar, the one that is titled with the application?s name and sits next to the Apple menu. Currently JavaFX builds this menu internally and it?s not customizable in any way (it can?t even be localized). This menu used to require special handling at the OS level but those days are long gone so there?s no technical reason a developer can?t just replace it wholesale.

The implementation is more straightforward than the documentation. JavaFX has never documented the presence of this menu and it exhibits some unique behavior. The application menu is always present even for JavaFX applications that don?t use the system menu bar or MenuBars in general. And unlike other JavaFX menus the application menu is accessible when all windows are iconified. The application menu lives in a separate space from the per-window menus and we now need to document that.

The new API allows a developer to replace the application menu with a list of menus which I call the common menus. Like the current application menu the common menus are always present. Any menus provided by a MenuBar with setUseSystemMenu set to true will appear alongside the common menus. In theory a JavaFX developer could go full Mac-like and install a single set of common menus at application launch and forego per-window menus altogether. Or they could just replace the application menu and continue using per-window MenuBar?s in keeping with the JavaFX idiom.

The application menu contains some items which require platform support (Hide, Hide Others, and Show All) and I wasn?t sure where to put those calls. I?m still not sure. I welcome feedback on that and any other part of this proposed API.

From kevin.rushforth at oracle.com  Tue Sep  2 15:40:25 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 2 Sep 2025 08:40:25 -0700
Subject: JavaFX 25.0.1 will be closed for fixes on September 9th
Message-ID: <ae911797-8fc5-4fcc-888c-203630eb2265@oracle.com>

All,

If you have backports that you want to get into jfx25u [1] for JavaFX 
25.0.1, please do so by Monday, September 8th, 2025. Note that approval 
from one of the project leads is needed as outlined in this message [2].

Starting Tuesday, September 9th, jfx25u will be open for JavaFX 25.0.2 
fixes.

Thanks.

-- Kevin

[1] https://github.com/openjdk/jfx25u
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2025-July/055496.html


From mfox at openjdk.org  Tue Sep  2 16:27:14 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 2 Sep 2025 16:27:14 GMT
Subject: RFR: 8366568: Allow replacing built in application menu in system
 menu bar [v2]
In-Reply-To: <bvW8so_fpqLcJ8MlTeht41leQ0mnot605eArY2DkRtk=.3eebc5bb-f923-4499-a2e7-b83aef11cdad@github.com>
References: <bvW8so_fpqLcJ8MlTeht41leQ0mnot605eArY2DkRtk=.3eebc5bb-f923-4499-a2e7-b83aef11cdad@github.com>
Message-ID: <OQytYLTzEvoM0bpWT6ftMi_QQDl3TzYcc5DdtgDDhKs=.d05d188b-9dd4-4c32-87ef-414408861b40@github.com>

> This PR provides an API for replacing the application menu that JavaFX places in the system menu bar on macOS. The application menu is the one next to the Apple menu that is titled with the application's name and contains the Quit menu item. The JavaFX version of this menu has many limitations so this PR allows a developer to simply replace it outright.
> 
> Technically there?s no reason to restrict this to only one menu so the API allows the developer to specify an observable list of Menus known as the common system menus. Like the current application menu the common menus are present for all JavaFX windows and remain present even if all windows lose focus. Any per-window menus provided by a MenuBar with useSystemMenuBar set will appear alongside the common system menus.
> 
> In addition the PR provides some calls that allow a developer to implement the Hide <app name>, Hide Others, and Show All menu items that are expected in the application menu.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Quick fix for a javadoc issue.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1881/files
  - new: https://git.openjdk.org/jfx/pull/1881/files/1b946f27..e9346431

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

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

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

From michaelstrau2 at gmail.com  Tue Sep  2 16:30:33 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 2 Sep 2025 18:30:33 +0200
Subject: Proposing an API for replacing the application menu on macOS
In-Reply-To: <31E81814-652D-4741-9E0B-F89B6D5A90C3@gmail.com>
References: <31E81814-652D-4741-9E0B-F89B6D5A90C3@gmail.com>
Message-ID: <CAJEpuXQtZMLowje=WvQFojFLdAut=MM2TF=qEQzMEPTLaG2=nw@mail.gmail.com>

This seems like a useful feature, but I have some comments on the
proposed implementation.

JavaFX purposefully differentiates between the javafx.graphics and
javafx.controls module. The javafx.graphics module is the core API,
it's what users can't recreate themselves. These are not only JavaFX
primitives like the scene graph, but also platform bindings.

The javafx.controls module, on the other hand, is _one_ implementation
of a controls toolkit. Third-party developers should be able, in
theory, to create their own controls toolkit with the APIs provided by
javafx.graphics. Even if this is not actually done in practice, it is
architecturally unsound to have javafx.graphics depend on
javafx.controls, or to have controls interact with graphics in ways
which can't be recreated by third-party developers.

System menu bars are one example of where javafx.controls is
privileged, and your proposal would further cement this special
status. What I think we should do instead is the following:

1. Provide a core menu API in javafx.graphics
2. Have the menus in javafx.controls implement this core API

(Note that there already exists something resembling a core API for menus.)

This not only provides a well-defined API, but also allows us to take
a new look at the implementation of an application menu. If the
application menu is associated with the application instance, then
maybe the Application class would be a more natural home for the app
menu API instead of a static property on the MenuBar control.



On Tue, Sep 2, 2025 at 5:34?PM Martin Fox <martinfox656 at gmail.com> wrote:
>
> I?ve submitted a draft PR (#1881) with an API that allows a JavaFX developer to replace the application menu on macOS. This is the first menu in the system menu bar, the one that is titled with the application?s name and sits next to the Apple menu. Currently JavaFX builds this menu internally and it?s not customizable in any way (it can?t even be localized). This menu used to require special handling at the OS level but those days are long gone so there?s no technical reason a developer can?t just replace it wholesale.
>
> The implementation is more straightforward than the documentation. JavaFX has never documented the presence of this menu and it exhibits some unique behavior. The application menu is always present even for JavaFX applications that don?t use the system menu bar or MenuBars in general. And unlike other JavaFX menus the application menu is accessible when all windows are iconified. The application menu lives in a separate space from the per-window menus and we now need to document that.
>
> The new API allows a developer to replace the application menu with a list of menus which I call the common menus. Like the current application menu the common menus are always present. Any menus provided by a MenuBar with setUseSystemMenu set to true will appear alongside the common menus. In theory a JavaFX developer could go full Mac-like and install a single set of common menus at application launch and forego per-window menus altogether. Or they could just replace the application menu and continue using per-window MenuBar?s in keeping with the JavaFX idiom.
>
> The application menu contains some items which require platform support (Hide, Hide Others, and Show All) and I wasn?t sure where to put those calls. I?m still not sure. I welcome feedback on that and any other part of this proposed API.

From angorya at openjdk.org  Tue Sep  2 17:04:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Sep 2025 17:04:57 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
Message-ID: <wg2WDjOLoi6ohUPGL_O0nrZwhwm1q8XS0c0-WL4yrcw=.01dce1a5-c111-4b34-95d4-4cdebc6aa05c@github.com>

On Sat, 30 Aug 2025 15:46:29 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing @since

Yes, calling `startFullDrag()` did the trick:


{event=MOUSE_DRAGGED, x/y=(-785, -106), screen=(19, 57), scene=-360, -67)}
{event=MOUSE-DRAG_DONE, x/y=(-785, -106), screen=(19, 57), scene=-360, -67)}
{event=MOUSE_RELEASED, x/y=(-785, -106), screen=(19, 57), scene=-360, -67)}


Question: should we explain in greater detail that the new event is coming during full drag only?

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3246124666

From kcr at openjdk.org  Tue Sep  2 17:04:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:04:57 GMT
Subject: [jfx25u] RFR: Merge jfx:jfx25
Message-ID: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>

Clean merge of `jfx:jfx25` into `jfx25u:master`

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

Commit messages:
 - Merge remote-tracking branch 'jfx/jfx25' into merge-jfx-jfx25-to-master-2025-09-02
 - 8365763: Update copyright header for files modified in 2025

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx25u/pull/8/files
  Stats: 118 lines in 118 files changed: 0 ins; 0 del; 118 mod
  Patch: https://git.openjdk.org/jfx25u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/8/head:pull/8

PR: https://git.openjdk.org/jfx25u/pull/8

From angorya at openjdk.org  Tue Sep  2 17:10:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Sep 2025 17:10:49 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
Message-ID: <tmV30IwJfmMTRWhTEMiXKFSLwIwmGyw9Qy3b50XNkVo=.ebe6ca4a-6ce5-433b-8501-5c1358971a3b@github.com>

On Sat, 30 Aug 2025 15:46:29 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing @since

This is only tangentially related, but why in the drag and drop mode the coordinates for DRAG_DONE event are completely bogus when drop happens over a non-accepting target?


{event=DRAG_EXITED, x/y=(52, 32), screen=(1022, -1340), scene=(477, 71)}
{event=DRAG_EXITED_TARGET, x/y=(52, 32), screen=(1022, -1340), scene=(477, 71)}
{event=DRAG_DONE, x/y=(0, 0), screen=(0, 0), scene=(0, 0)}

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3246142050

From angorya at openjdk.org  Tue Sep  2 17:14:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Sep 2025 17:14:54 GMT
Subject: [jfx25u] RFR: Merge jfx:jfx25
In-Reply-To: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
References: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
Message-ID: <nVtXClTiHKWrmV5lKMcXidg2Qio0-crpVWomhbthRUc=.c23a59df-7fed-49de-87da-83e7eb0994a4@github.com>

On Tue, 2 Sep 2025 16:59:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of `jfx:jfx25` into `jfx25u:master`

in the year 2025...

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx25u/pull/8#pullrequestreview-3177456654

From kcr at openjdk.org  Tue Sep  2 17:15:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:15:28 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
Message-ID: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>

This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).

The following filter was used to produce the list of issues fixed in JavaFX 25:

https://bugs.openjdk.org/issues/?filter=47140

Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

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

Commit messages:
 - Removed bugs that were both introduced and fixed in jfx25
 - Escape literal `<br>` in issue title
 - 8365515: Create release notes for JavaFX 25

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

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

From duke at openjdk.org  Tue Sep  2 17:15:28 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Tue, 2 Sep 2025 17:15:28 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <PIFuLadUUaIaXwqCLkd5Y4BZUaSIxi4NuUaqblX1wzE=.067ce75d-6a5c-449a-b965-9d82f9c5af08@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

LGTM atm. Will have a look again when the PR is moved out of draft.

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

Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3130654864

From kcr at openjdk.org  Tue Sep  2 17:15:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:15:29 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <bO8eX9uBkxDvitZAv9Q3vjTblOVutzxHemWaYcLR4Rs=.ce1d33a5-bd24-4941-a211-1252a1f436e4@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <bO8eX9uBkxDvitZAv9Q3vjTblOVutzxHemWaYcLR4Rs=.ce1d33a5-bd24-4941-a211-1252a1f436e4@github.com>
Message-ID: <KNMMx5keFz3Uc0YgILuGzcvZ6mjnSDrxsa9ENbjgNK0=.47b66c08-1337-4e9f-ae5d-3c588434a2dc@github.com>

On Tue, 19 Aug 2025 14:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> doc-files/release-notes-25.md line 125:
> 
>> 123: [JDK-8354813](https://bugs.openjdk.org/browse/JDK-8354813) | Parent.isNeedsLayout() may return wrong value in property listener | graphics
>> 124: [JDK-8357004](https://bugs.openjdk.org/browse/JDK-8357004) | Windows platform color changes are not picked up in some cases | graphics
>> 125: [JDK-8358454](https://bugs.openjdk.org/browse/JDK-8358454) | Wrong <br> tags in cssref.html  | graphics
> 
> `<br>` creates an actual line break

Thanks. Fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2285681248

From angorya at openjdk.org  Tue Sep  2 17:15:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Sep 2025 17:15:29 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <bO8eX9uBkxDvitZAv9Q3vjTblOVutzxHemWaYcLR4Rs=.ce1d33a5-bd24-4941-a211-1252a1f436e4@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

thanks!

Marked as reviewed by angorya (Reviewer).

doc-files/release-notes-25.md line 125:

> 123: [JDK-8354813](https://bugs.openjdk.org/browse/JDK-8354813) | Parent.isNeedsLayout() may return wrong value in property listener | graphics
> 124: [JDK-8357004](https://bugs.openjdk.org/browse/JDK-8357004) | Windows platform color changes are not picked up in some cases | graphics
> 125: [JDK-8358454](https://bugs.openjdk.org/browse/JDK-8358454) | Wrong <br> tags in cssref.html  | graphics

`<br>` creates an actual line break

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3133070807
PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3177453219
PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2285455040

From kcr at openjdk.org  Tue Sep  2 17:15:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:15:29 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <Q4Nn1F9KKCvLPTI_mokUPJjLexVL5_ELs95NOJ8996k=.3cec04c2-cfbb-41f6-80e0-0f10626a2ccd@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

Reviewers: Some combination of @abhinayagarwal @johanvos @andy-goryachev-oracle @arapte 

This should be pretty close to the final version. We do have 1.5 weeks of RDP2 left, so there is still the possibility of a P2 bug getting fixed and backported to jfx25. For this reason, I will leave the PR in Draft until after RDP2 ends and we have produced the first RC build.

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

PR Comment: https://git.openjdk.org/jfx/pull/1871#issuecomment-3197495445

From mstrauss at openjdk.org  Tue Sep  2 17:15:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 2 Sep 2025 17:15:29 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <3YAh5uE4bGgdmitVcJRFxGbp8wA4jXtcNMtc0nZaaKc=.d87c0d0f-f898-4465-9aba-533f23dbf7a4@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

doc-files/release-notes-25.md line 153:

> 151: [JDK-8359601](https://bugs.openjdk.org/browse/JDK-8359601) | Fix window button states of an extended stage | window-toolkit
> 152: [JDK-8359763](https://bugs.openjdk.org/browse/JDK-8359763) | Close request handler is not called for an extended stage | window-toolkit
> 153: [JDK-8362095](https://bugs.openjdk.org/browse/JDK-8362095) | HeaderButtonMetrics should not be used across toolkit boundary | window-toolkit

[JDK-8359601](https://bugs.openjdk.org/browse/JDK-8359601), [JDK-8359763](https://bugs.openjdk.org/browse/JDK-8359763), and [JDK-8362095](https://bugs.openjdk.org/browse/JDK-8362095) are bugs that are introduced and fixed in the same JFX version, and should probably be removed from the release notes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2296732376

From kcr at openjdk.org  Tue Sep  2 17:15:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:15:29 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <3YAh5uE4bGgdmitVcJRFxGbp8wA4jXtcNMtc0nZaaKc=.d87c0d0f-f898-4465-9aba-533f23dbf7a4@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <3YAh5uE4bGgdmitVcJRFxGbp8wA4jXtcNMtc0nZaaKc=.d87c0d0f-f898-4465-9aba-533f23dbf7a4@github.com>
Message-ID: <w_5Q1PqvjGllIN_00XGNfL5jUWpqRlF0Sdz0mAEqGgE=.3bb9b144-8711-46cd-b7df-6148ed33317d@github.com>

On Sun, 24 Aug 2025 16:43:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> doc-files/release-notes-25.md line 153:
> 
>> 151: [JDK-8359601](https://bugs.openjdk.org/browse/JDK-8359601) | Fix window button states of an extended stage | window-toolkit
>> 152: [JDK-8359763](https://bugs.openjdk.org/browse/JDK-8359763) | Close request handler is not called for an extended stage | window-toolkit
>> 153: [JDK-8362095](https://bugs.openjdk.org/browse/JDK-8362095) | HeaderButtonMetrics should not be used across toolkit boundary | window-toolkit
> 
> [JDK-8359601](https://bugs.openjdk.org/browse/JDK-8359601), [JDK-8359763](https://bugs.openjdk.org/browse/JDK-8359763), and [JDK-8362095](https://bugs.openjdk.org/browse/JDK-8362095) are bugs that are introduced and fixed in the same JFX version, and should probably be removed from the release notes.

Good catch. Done.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2316690096

From kcr at openjdk.org  Tue Sep  2 17:21:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:21:33 GMT
Subject: [jfx25u] RFR: Merge jfx:jfx25 [v2]
In-Reply-To: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
References: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
Message-ID: <nQMZ2EVq27JGZK-IjURk0RHj1YmjXbht_Jhbp4K6LBQ=.cf0058a1-a45a-4aeb-8a5e-971cc66e0af9@github.com>

> Clean merge of `jfx:jfx25` into `jfx25u:master`

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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'jfx/jfx25' into merge-jfx-jfx25-to-master-2025-09-02
 - Merge
 - 8356982: Update WebKit to 622.1
   8328684: HellowWebView demo crashes when a webpage is scrolled
   8360270: Websocket communication issues with Vaadin applications through webview
   
   Reviewed-by: kcr
   Backport-of: 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1
 - 8361648: Update Glib to 2.84.3
   
   Backport-of: f9532842b0765472c7490fb5bbf57cf268dd45ee
 - Merge
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos
   
   Reviewed-by: jvos
   Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6
 - 8362896: Change JavaFX release version to 25.0.1 in jfx25u
   
   Reviewed-by: angorya

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

Changes:
  - all: https://git.openjdk.org/jfx25u/pull/8/files
  - new: https://git.openjdk.org/jfx25u/pull/8/files/fd6598fb..fd6598fb

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jfx25u&pr=8&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx25u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/8/head:pull/8

PR: https://git.openjdk.org/jfx25u/pull/8

From kcr at openjdk.org  Tue Sep  2 17:21:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Sep 2025 17:21:33 GMT
Subject: [jfx25u] Integrated: Merge jfx:jfx25
In-Reply-To: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
References: <B6trNcsmzk_7OL2b2D--D-4S4KaQx2M9kDDUIkqUy7w=.4d0b2327-b952-4d3a-99fe-511b35e727ef@github.com>
Message-ID: <omwEBYsBNK45V1KiqbieDUUye-DnzZbwUfJo5rlLfYc=.62fbb94e-a614-453c-b0b6-628abddb1163@github.com>

On Tue, 2 Sep 2025 16:59:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of `jfx:jfx25` into `jfx25u:master`

This pull request has now been integrated.

Changeset: 3e32db88
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/3e32db8860a739e415184614299004de8d2acde5
Stats:     118 lines in 118 files changed: 0 ins; 0 del; 118 mod

Merge

Reviewed-by: angorya

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

PR: https://git.openjdk.org/jfx25u/pull/8

From mstrauss at openjdk.org  Tue Sep  2 17:48:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 2 Sep 2025 17:48:49 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <LFHr_xvhasc8orBF0koqc3txYgifuRmfNSX4I5EytsE=.ec5847a4-2668-46bb-8e5c-69aa66e73e32@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3177559445

From andy.goryachev at oracle.com  Tue Sep  2 20:16:46 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 2 Sep 2025 20:16:46 +0000
Subject: [External] : Re: Bug: ToolBar always using overflow menu whenever
 a scaled resolution set
In-Reply-To: <CAG_-AaBVxOUEn2patSBunJZbWMNTc08YtV6-T_j5oaKaYAsCbw@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
 <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
 <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaCoBdRWyJZka_aRZsZ-23NCf=im=R+m7fJ7jfwtrOnvxg@mail.gmail.com>
 <b8be6f75-6665-4a51-948c-03288f46a56d@oracle.com>
 <52a3bca8-1ade-45d1-851c-4d8d9bba22d7@oracle.com>
 <CAG_-AaBVxOUEn2patSBunJZbWMNTc08YtV6-T_j5oaKaYAsCbw@mail.gmail.com>
Message-ID: <CY8PR10MB7265A71604950A5B38C2F645E506A@CY8PR10MB7265.namprd10.prod.outlook.com>

Created https://bugs.openjdk.org/browse/JDK-8366739

Thanks!
-andy

From: Cormac Redmond <credmond at certak.com>
Date: Friday, August 29, 2025 at 17:20
To: Kevin Rushforth <kevin.rushforth at oracle.com>, Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Bug: ToolBar always using overflow menu whenever a scaled resolution set

Hi,

A variation of this bug still persists (JFX 25-ea+28).

Run this code (125% display scaling, on Windows):

public class ToolbarBugApp extends Application {

    @Override
    public void start(Stage primaryStage) {
        ToolBar tb = new ToolBar();
        tb.getItems().addAll(
                new Separator(Orientation.VERTICAL),
                new Button("Create Schema")
        );

        BorderPane bp = new BorderPane();
        bp.setTop(new HBox(tb));
        primaryStage.setScene(new Scene(bp, 600, 400));
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

And you'll still see this:

[image.png]



Kind Regards,
Cormac

On Thu, 24 Jul 2025 at 16:12, Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>> wrote:
https://bugs.openjdk.org/browse/JDK-8364049


On 7/24/2025 7:15 AM, Kevin Rushforth wrote:
This does look like a real bug. Thanks for filing it.

Unfortunately one cannot attach screenshots on JBS submissions, so a text description will have to do.

I have attached the two images to the bug. It will show up publicly, with a JDK bug ID, soon.

-- Kevin


On 7/23/2025 3:17 PM, Cormac Redmond wrote:
I've a habit of finding non-bugs, so prefer to discuss it first to get some feedback (and/or to avoid duplicating known bugs), but I assume this is definitely an issue, so I created it on JBS now: 9078765...

Unfortunately one cannot attach screenshots on JBS submissions, so a text description will have to do.

Thanks!


Kind Regards,
Cormac

On Wed, 23 Jul 2025 at 20:30, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
Do we have the JBS ticket filed for this issue?

-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: Tuesday, July 22, 2025 at 12:08
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: Bug: ToolBar always using overflow menu whenever a scaled resolution set

Any thoughts on this? It seems like a definite JavaFX bug with hopefully a simple fix. Choosing any fractional scaled resolution may or may not cause the issue. I also wonder what other controls may suffer from the same issues.

On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi,

I've traced the bug down to a rounding error. See the below screenshot in ToolBarSkin's getOverflowNodeIndex(double length).

These two numbers are not equal, but should be. snapSizeX() ultimately ends up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1 (i.e., no scaling), we don't see this issue. If it's 1.25, we see this rounding difference between the two numbers in this instance. If these two numbers are not equal, the calling code mistakenly assumes the overflow box is necessary.

[cid:ii_198f855ec54cb971f161]

Can someone fix this?



Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Confusingly, make the string longer, such as "Create Schema 123 123 123":

        bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123 123"))));

...and the overflow doesn't appear (but still, anything between and including 13-24, it does):

[cid:ii_198f855ec54cb971f162]




Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi,

There's a bug whenever using a ToolBar on Windows if you set your resolution scale > 100% (which is quite common). E.g., 125%:

[cid:ii_198f855ec54cb971f163]

E.g., this is what a ToolBar always renders if scale is 125%:

[cid:ii_198f855ec54cb971f164]

As compared to what you'd expect (scale set to normal/100%):

[cid:ii_198f855ec54cb971f165]

Very easy to reproduce the above, set your scale to 125% and run this:

public class ToolbarBugApp extends Application {

    @Override
    public void start(Stage primaryStage) {
        BorderPane bp = new BorderPane();
        // Wrapping in HBox and using button with 13+ chars causes bug
        bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); // BUG
        // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG (no HBox)
        // bp.setTop(new HBox(new ToolBar(new Button("Create Schem")))); // NO BUG (12 chars)
        primaryStage.setScene(new Scene(bp, 600, 400));
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

As per the comments, this bug appears to happen when your ToolBar is wrapped in a HBox and contains a Button that has 13+ characters, for example. This is quite a serious bug, in my opinion.

I believe this is present in JFX 24 and the JFX 25 master branch.


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!M6R849v9_bV5Pkvo4auFUSshSOXA8efSdEow3bYTGKe4AradVePKerHgau3LuQu4lPlgYX4BohVEyhrG_LJyqA$>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14019 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5bb1e802/image-0011.png>

From crschnick at xpipe.io  Tue Sep  2 21:08:15 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 2 Sep 2025 23:08:15 +0200
Subject: Invalid stage iconified coordinates on Windows
Message-ID: <e3ced1f9-d0fc-42a9-a374-754b0d7e3675@xpipe.io>

Hello,

I encountered an issue on Windows where the xProperty() and yProperty() 
of stages will be set to the special value -32000 when an iconified 
stage is closed. Simply calling .setIconified(true) on a stage and 
closing the window in the taskbar sends updates to any listeners with 
this value.

I understand that in the win32 API, this value is used to indicate that 
the window is iconified. But in my opinion the JavaFX state should not 
return that and instead keep the last x/y coordinates of where it was 
when it was iconified, so I assume that this is a bug.

In practice, this breaks various situations in which the application 
will store the last window coordinates for the next time it is opened. 
If the application is closed while the stage was iconified, the stage 
won't show again as it is off the screen.

This happens in the latest ea build.

Here is a reproducer:

public static void main(String[] args) {
     Platform.startup(() -> {
         var stage =new Stage();
         stage.setWidth(500);
         stage.setHeight(500);
         stage.show();
         stage.setIconified(true);
         stage.xProperty().subscribe(number -> System.out.println(number));
         stage.hide();
         stage.show();
     });
}

Best
Christopher Schnick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250902/5fd8f2fe/attachment.htm>

From nlisker at openjdk.org  Tue Sep  2 21:23:49 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 2 Sep 2025 21:23:49 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: <wg2WDjOLoi6ohUPGL_O0nrZwhwm1q8XS0c0-WL4yrcw=.01dce1a5-c111-4b34-95d4-4cdebc6aa05c@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 <wg2WDjOLoi6ohUPGL_O0nrZwhwm1q8XS0c0-WL4yrcw=.01dce1a5-c111-4b34-95d4-4cdebc6aa05c@github.com>
Message-ID: <SXlnS8-XhFniW2NfQF-1rUUC-14598hZy2mj5TOgywI=.e29b3a71-e7ed-4319-bbd7-e8a59b063856@github.com>

On Tue, 2 Sep 2025 17:02:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Question: should we explain in greater detail that the new event is coming during full drag only?

It's an event type of `MouseDragEvent`, which is the event used in full PDR, so I don't think there's an ambiguity here. I have a future docs change in the works around mouse events that clears up a lot of things.

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3246824027

From nlisker at openjdk.org  Tue Sep  2 21:40:52 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 2 Sep 2025 21:40:52 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: <tmV30IwJfmMTRWhTEMiXKFSLwIwmGyw9Qy3b50XNkVo=.ebe6ca4a-6ce5-433b-8501-5c1358971a3b@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 <tmV30IwJfmMTRWhTEMiXKFSLwIwmGyw9Qy3b50XNkVo=.ebe6ca4a-6ce5-433b-8501-5c1358971a3b@github.com>
Message-ID: <Rg4Gg1sw88JK4M0LGcofRnigOkl8S7LSYglUlxzi4FM=.8a9630ec-0b8f-4a99-9b28-a692237cff03@github.com>

On Tue, 2 Sep 2025 17:08:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This is only tangentially related, but why in the drag and drop mode the coordinates for DRAG_DONE event are completely bogus when drop happens over a non-accepting target?

I don't know why it was done this way, but the coordinates are explicitly set to 0 from `GlassScene.createDragboard` and `GlassSceneDnDEventHandler.handleDragEnd`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3246884842

From nlisker at openjdk.org  Tue Sep  2 21:59:48 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 2 Sep 2025 21:59:48 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <T8HCGdHmmVY0G38SlBaTHt4Xgd7Y7t3_70WBjnG93xA=.2d22c3e5-2dcf-46da-8f6b-9ca7b681c565@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

doc-files/release-notes-25.md line 139:

> 137: [JDK-8352162](https://bugs.openjdk.org/browse/JDK-8352162) | Update libxml2 to 2.13.8 | web
> 138: [JDK-8352164](https://bugs.openjdk.org/browse/JDK-8352164) | Update libxslt to 1.1.43 | web
> 139: [JDK-8353916](https://bugs.openjdk.org/browse/JDK-8353916) | Unexpected event type for DOM mutation events with WebKit 620.1 | web

There are various issues fixed for WebKit 620.1 while only in this JavaFX version that WebKit version was introduced. Is it really meaningful to specify them?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2317257071

From jhendrikx at openjdk.org  Wed Sep  3 09:32:53 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 3 Sep 2025 09:32:53 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v3]
In-Reply-To: <o26WYxX98VqG3yaGyL4VOjluVD_w3rqFxbW5V_wmXrU=.20fba89c-3b99-4e5e-933d-3ab5dd70fb51@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <zC6dOoZi_f2wmgF1vRatqmMd_naJanlT8NrKNGi4rS4=.4f4129c6-a978-4c39-be00-1dec1c22c273@github.com>
 <o26WYxX98VqG3yaGyL4VOjluVD_w3rqFxbW5V_wmXrU=.20fba89c-3b99-4e5e-933d-3ab5dd70fb51@github.com>
Message-ID: <o3rtt6Dof9q_Z_QA4VFpTTDg4Etpi3sKUKFL94co2Wk=.6faff04e-cbce-4138-9c21-723c9620203e@github.com>

On Fri, 29 Aug 2025 16:24:45 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/relaxed-interpolation
>>  - javadoc
>>  - Allow interpolation outside of range [0,1]
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/paint/RadialGradientTest.java line 291:
> 
>> 289:         try {
>> 290:             RadialGradient.valueOf("radial-gradient(radius -100, red 0%, blue 30%, black 100%)");
>> 291:             fail("IllegalArgument should have been thrown.");
> 
> nice: these tests do more than a simple `assertThrows` would do.

You can do this actually as `assertThrows` returns the exception thrown:

            assertEquals("message", assertThrows(
                IllegalArgumentException.class, 
                () -> RadialGradient.valueOf("radial-gradient(radius -100, red 0%, blue 30%, black 100%)")
            ).getMessage());

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2318372856

From jhendrikx at openjdk.org  Wed Sep  3 11:42:02 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 3 Sep 2025 11:42:02 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v19]
In-Reply-To: <RhRGP4XEJLGvfNtz_pFDJ5kUYbjBeRXH-2r70JmaXWo=.a515318b-b19d-44b7-a63b-698b17e01277@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <RhRGP4XEJLGvfNtz_pFDJ5kUYbjBeRXH-2r70JmaXWo=.a515318b-b19d-44b7-a63b-698b17e01277@github.com>
Message-ID: <pcRyuL79DvWhpOn0bB-D-nu3WRrsc5UcGOWpJc6NNkg=.9cde3829-c425-4d10-bbaf-23fd8c08f5da@github.com>

On Sun, 8 Jun 2025 11:18:51 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 one additional commit since the last revision:
> 
>   Fix broken test case (after bad asserts were fixed)

Keep it open.

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

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

From kcr at openjdk.org  Wed Sep  3 13:01:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 13:01:56 GMT
Subject: RFR: 8366568: Allow replacing built in application menu in system
 menu bar [v2]
In-Reply-To: <OQytYLTzEvoM0bpWT6ftMi_QQDl3TzYcc5DdtgDDhKs=.d05d188b-9dd4-4c32-87ef-414408861b40@github.com>
References: <bvW8so_fpqLcJ8MlTeht41leQ0mnot605eArY2DkRtk=.3eebc5bb-f923-4499-a2e7-b83aef11cdad@github.com>
 <OQytYLTzEvoM0bpWT6ftMi_QQDl3TzYcc5DdtgDDhKs=.d05d188b-9dd4-4c32-87ef-414408861b40@github.com>
Message-ID: <JDPUNMcgKNosEF0IU04Si2s92ceK8hFipUzK11wFF84=.e6853af0-3caa-4391-a7da-17989bba2f91@github.com>

On Tue, 2 Sep 2025 16:27:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> This PR provides an API for replacing the application menu that JavaFX places in the system menu bar on macOS. The application menu is the one next to the Apple menu that is titled with the application's name and contains the Quit menu item. The JavaFX version of this menu has many limitations so this PR allows a developer to simply replace it outright.
>> 
>> Technically there?s no reason to restrict this to only one menu so the API allows the developer to specify an observable list of Menus known as the common system menus. Like the current application menu the common menus are present for all JavaFX windows and remain present even if all windows lose focus. Any per-window menus provided by a MenuBar with useSystemMenuBar set will appear alongside the common system menus.
>> 
>> In addition the PR provides some calls that allow a developer to implement the Hide <app name>, Hide Others, and Show All menu items that are expected in the application menu.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Quick fix for a javadoc issue.

The idea seems interesting. It will need discussion on the mailing list, which I see you've started.

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

PR Comment: https://git.openjdk.org/jfx/pull/1881#issuecomment-3249153082

From kcr at openjdk.org  Wed Sep  3 15:28:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 15:28:54 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <T8HCGdHmmVY0G38SlBaTHt4Xgd7Y7t3_70WBjnG93xA=.2d22c3e5-2dcf-46da-8f6b-9ca7b681c565@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <T8HCGdHmmVY0G38SlBaTHt4Xgd7Y7t3_70WBjnG93xA=.2d22c3e5-2dcf-46da-8f6b-9ca7b681c565@github.com>
Message-ID: <lSp07ahsFVmKeObUUytREKAsfusB8fu0_BKz6q9u7-g=.d67dae95-58fa-48b2-97d2-8e47b2e375da@github.com>

On Tue, 2 Sep 2025 21:56:50 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> doc-files/release-notes-25.md line 139:
> 
>> 137: [JDK-8352162](https://bugs.openjdk.org/browse/JDK-8352162) | Update libxml2 to 2.13.8 | web
>> 138: [JDK-8352164](https://bugs.openjdk.org/browse/JDK-8352164) | Update libxslt to 1.1.43 | web
>> 139: [JDK-8353916](https://bugs.openjdk.org/browse/JDK-8353916) | Unexpected event type for DOM mutation events with WebKit 620.1 | web
> 
> There are various issues fixed for WebKit 620.1 while only in this JavaFX version that WebKit version was introduced. Is it really meaningful to specify them?

Yes, these should be excluded for the same reason as the ones Michael pointed out above: they are transient bugs that were introduced and fixed in the same version, so will not be seen by anyone migrating from jfx24 to jfx25.

I'll add a `javafx-rn-exclude` label to the 5 follow-on WebKit 620.1 bugs (setting the "introduced-in-release" field won't do it for these, since that would be the update release of the earliest release family).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2319338259

From kcr at openjdk.org  Wed Sep  3 17:09:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 17:09:25 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25 [v2]
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Exclude more bugs that were both introduced and fixed in jfx25

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1871/files
  - new: https://git.openjdk.org/jfx/pull/1871/files/83646462..898522f8

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

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

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

From nlisker at openjdk.org  Wed Sep  3 17:11:51 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 3 Sep 2025 17:11:51 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25 [v2]
In-Reply-To: <lSp07ahsFVmKeObUUytREKAsfusB8fu0_BKz6q9u7-g=.d67dae95-58fa-48b2-97d2-8e47b2e375da@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <T8HCGdHmmVY0G38SlBaTHt4Xgd7Y7t3_70WBjnG93xA=.2d22c3e5-2dcf-46da-8f6b-9ca7b681c565@github.com>
 <lSp07ahsFVmKeObUUytREKAsfusB8fu0_BKz6q9u7-g=.d67dae95-58fa-48b2-97d2-8e47b2e375da@github.com>
Message-ID: <4XQxnn4oc-hpu3a3iJenP2XRQN4uZi-AY_Fye9FxYR0=.9a8a680c-f8b2-47f3-a3bc-48970fa1c308@github.com>

On Wed, 3 Sep 2025 15:25:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-25.md line 139:
>> 
>>> 137: [JDK-8352162](https://bugs.openjdk.org/browse/JDK-8352162) | Update libxml2 to 2.13.8 | web
>>> 138: [JDK-8352164](https://bugs.openjdk.org/browse/JDK-8352164) | Update libxslt to 1.1.43 | web
>>> 139: [JDK-8353916](https://bugs.openjdk.org/browse/JDK-8353916) | Unexpected event type for DOM mutation events with WebKit 620.1 | web
>> 
>> There are various issues fixed for WebKit 620.1 while only in this JavaFX version that WebKit version was introduced. Is it really meaningful to specify them?
>
> Yes, these should be excluded for the same reason as the ones Michael pointed out above: they are transient bugs that were introduced and fixed in the same version, so will not be seen by anyone migrating from jfx24 to jfx25.
> 
> I'll add a `javafx-rn-exclude` label to the 5 follow-on WebKit 620.1 bugs (setting the "introduced-in-release" field won't do it for these, since that would be the update release of the earliest release family).

JDK-8350284 has affected versions set from before 620.1 somehow. This is why it was confusing.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1871#discussion_r2319641198

From kcr at openjdk.org  Wed Sep  3 17:14:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 17:14:34 GMT
Subject: [jfx25u] RFR: 8366732: Change JavaFX release version to 25.0.2 in
 jfx25u
Message-ID: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>

Bump release version to 25.0.2.

I will integrate this on Tuesday, Sep 9th, 2025 in the morning (Pacific).

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

Commit messages:
 - 8366732: Change JavaFX release version to 25.0.2 in jfx25u

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

PR: https://git.openjdk.org/jfx25u/pull/9

From kcr at openjdk.org  Wed Sep  3 17:14:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 17:14:35 GMT
Subject: [jfx25u] RFR: 8366732: Change JavaFX release version to 25.0.2 in
 jfx25u
In-Reply-To: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
References: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
Message-ID: <mbVbH8YoeXSQtLRChZ3e6WhMGqBhnGKFFGgau9qOvSE=.36c61ae4-476b-4958-833c-139d376b6638@github.com>

On Wed, 3 Sep 2025 17:08:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version to 25.0.2.
> 
> I will integrate this on Tuesday, Sep 9th, 2025 in the morning (Pacific).

Reviewer: @johanvos

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

PR Comment: https://git.openjdk.org/jfx25u/pull/9#issuecomment-3250086036

From jvos at openjdk.org  Wed Sep  3 17:19:48 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 3 Sep 2025 17:19:48 GMT
Subject: [jfx25u] RFR: 8366732: Change JavaFX release version to 25.0.2 in
 jfx25u
In-Reply-To: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
References: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
Message-ID: <BUg0__aM66FV_F--8voe6NJCgy25qU6HIZkVt0ugQ8M=.2b5a6e3c-0117-485f-ac8e-9c7cd06a0437@github.com>

On Wed, 3 Sep 2025 17:08:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version to 25.0.2.
> 
> I will integrate this on Tuesday, Sep 9th, 2025 in the morning (Pacific).

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx25u/pull/9#pullrequestreview-3181706753

From angorya at openjdk.org  Wed Sep  3 17:26:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Sep 2025 17:26:55 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25 [v2]
In-Reply-To: <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
Message-ID: <fyiGiuoC7s94jVP4Gy67vffBwux8MvJnpku3DewsBFo=.e9f8fb57-3452-4dac-aaef-5400e1cf39ac@github.com>

On Wed, 3 Sep 2025 17:09:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude more bugs that were both introduced and fixed in jfx25

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3181730988

From tsayao at openjdk.org  Wed Sep  3 17:56:51 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 3 Sep 2025 17:56:51 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v57]
In-Reply-To: <mMDcz6FXkfWAznU1Eyay5tCTCXG9-uEwz6EQshsl2hQ=.6486e1be-37b9-46a6-b5dc-f78c4cb2a10d@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <mMDcz6FXkfWAznU1Eyay5tCTCXG9-uEwz6EQshsl2hQ=.6486e1be-37b9-46a6-b5dc-f78c4cb2a10d@github.com>
Message-ID: <DfQdYWvp5_QhdUIMmMH-qyamFwLVcFR0miFgv4TdfmQ=.815b4559-28d0-4548-a30f-5390a0b89eac@github.com>

On Sat, 23 Aug 2025 00:38:24 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.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - - Fix tests
>  - - Fix FOCUS_LOST begin sent on focused windows
>  - - Remove CenterOnScreenTest.java

Found one bug:

When the window is expanded (e.g. in an error dialog when "Show Details" is clicked), the stage grows as expected. However, when the content is collapsed again, the window does not shrink back to its previous size.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3250213029

From mstrauss at openjdk.org  Wed Sep  3 18:19:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 3 Sep 2025 18:19:50 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v3]
In-Reply-To: <o3rtt6Dof9q_Z_QA4VFpTTDg4Etpi3sKUKFL94co2Wk=.6faff04e-cbce-4138-9c21-723c9620203e@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <zC6dOoZi_f2wmgF1vRatqmMd_naJanlT8NrKNGi4rS4=.4f4129c6-a978-4c39-be00-1dec1c22c273@github.com>
 <o26WYxX98VqG3yaGyL4VOjluVD_w3rqFxbW5V_wmXrU=.20fba89c-3b99-4e5e-933d-3ab5dd70fb51@github.com>
 <o3rtt6Dof9q_Z_QA4VFpTTDg4Etpi3sKUKFL94co2Wk=.6faff04e-cbce-4138-9c21-723c9620203e@github.com>
Message-ID: <R5WS7mkvU17-JGAGocPrI9f5nW9YSGqU20pgoxXeI-0=.e52b56bd-85f5-4ef8-8f14-0bd7f40f0e53@github.com>

On Wed, 3 Sep 2025 09:29:33 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/java/test/javafx/scene/paint/RadialGradientTest.java line 291:
>> 
>>> 289:         try {
>>> 290:             RadialGradient.valueOf("radial-gradient(radius -100, red 0%, blue 30%, black 100%)");
>>> 291:             fail("IllegalArgument should have been thrown.");
>> 
>> nice: these tests do more than a simple `assertThrows` would do.
>
> You can do this actually as `assertThrows` returns the exception thrown:
> 
>             assertEquals("message", assertThrows(
>                 IllegalArgumentException.class, 
>                 () -> RadialGradient.valueOf("radial-gradient(radius -100, red 0%, blue 30%, black 100%)")
>             ).getMessage());

That's true, but I don't want to refactor all of the tests here at this time.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2319820527

From kcr at openjdk.org  Wed Sep  3 18:43:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 18:43:07 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
Message-ID: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>

This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.

In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.

This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.

This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

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

Commit messages:
 - 8365402: Bump minimum JDK version for JavaFX to JDK 24

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

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

From kcr at openjdk.org  Wed Sep  3 18:43:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 3 Sep 2025 18:43:07 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <-kf24bqMLhQqp5X9_wckzp0LuNhn9QNy1xGhb7ZdDuo=.f6ed86b2-fb6b-4fc2-818c-3a25d0d75e0b@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

Reviewers: @arapte and either @johanvos or @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1883#issuecomment-3250349815

From nlisker at openjdk.org  Wed Sep  3 22:19:28 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 3 Sep 2025 22:19:28 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
Message-ID: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>

Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.

Another option is to mark them as optional.

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

Commit messages:
 - Initial commit

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

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

From nlisker at openjdk.org  Wed Sep  3 22:19:28 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 3 Sep 2025 22:19:28 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
In-Reply-To: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
Message-ID: <chx2I5iD1ZptSYG27xRsDbLOe82jV9DTXcSn3EiWUGE=.158d8bf9-af68-4643-916f-f00e1841471a@github.com>

On Wed, 3 Sep 2025 22:14:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
> 
> Another option is to mark them as optional.

@andy-goryachev-oracle @hjohn Please review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1884#issuecomment-3250987791

From angorya at openjdk.org  Wed Sep  3 22:29:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Sep 2025 22:29:44 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
In-Reply-To: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
Message-ID: <RAZincWX0UIUCvwzN27Sa3eTieAz4kyCdWTSKVPQLIo=.54a189c7-e4a7-4791-bc36-6dc6e5dd8aca@github.com>

On Wed, 3 Sep 2025 22:14:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
> 
> Another option is to mark them as optional.

With this change I cannot run both jfx and standalone monkey testers:


JRE Oracle Corporation/24 is not supported, advanced source lookup disabled.
 Eclipse debugger will use less precise source lookup implementation for this debug session, but everything else will continue to work otherwise.
Upgrading Eclipse to the latest version will likely make this warning go away.RenderJob.run: internal exception
java.lang.ExceptionInInitializerError
	at javafx.graphics/com.sun.prism.mtl.MTLResourceFactory.<init>(MTLResourceFactory.java:61)
	at javafx.graphics/com.sun.prism.mtl.MTLPipeline.getResourceFactory(MTLPipeline.java:87)
	at javafx.graphics/com.sun.prism.mtl.MTLPipeline.getDefaultResourceFactory(MTLPipeline.java:78)
	at javafx.graphics/com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:155)
	at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.lambda$1(QuantumRenderer.java:155)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:369)
	at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1095)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:619)
	at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:122)
	at java.base/java.lang.Thread.run(Thread.java:1447)
Caused by: java.lang.RuntimeException: java.io.IOException: Stream closed
	at javafx.graphics/com.sun.prism.mtl.MTLContext.<clinit>(MTLContext.java:109)
	... 12 more
Caused by: java.io.IOException: Stream closed
	at java.base/java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:170)
	at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:328)
	at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:388)
	at java.base/java.io.InputStream.readNBytes(InputStream.java:411)
	at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
	at javafx.graphics/com.sun.prism.mtl.MTLContext.<clinit>(MTLContext.java:104)
	... 12 more

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

PR Comment: https://git.openjdk.org/jfx/pull/1884#issuecomment-3251005804

From nlisker at openjdk.org  Thu Sep  4 01:54:26 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 4 Sep 2025 01:54:26 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
 [v2]
In-Reply-To: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
Message-ID: <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>

> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
> 
> Another option is to mark them as optional.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Make OS-specific sources optional

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1884/files
  - new: https://git.openjdk.org/jfx/pull/1884/files/a20f7fe3..8a65063a

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

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

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

From nlisker at openjdk.org  Thu Sep  4 01:56:51 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 4 Sep 2025 01:56:51 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
In-Reply-To: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
Message-ID: <6Oe4-WhrSdCOLE-AmBIy-K5EDYWKs9mkj738yT75ClM=.9a14406f-49a3-4d76-b461-398f74bb8342@github.com>

On Wed, 3 Sep 2025 22:14:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
> 
> Another option is to mark them as optional.

Didn't see this in Metal. In any case, I reverted the removals and made the dependencies optional to avoid compilation errors on OS's that don't generate the required sources. This is much safer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1884#issuecomment-3251416265

From arapte at openjdk.org  Thu Sep  4 04:25:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 4 Sep 2025 04:25:46 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <PDxwMi3f2XcMYpuNbfHWBZGkjYyDUBrF7_y6FAemSok=.fd8f35c4-9592-4d72-acc5-09e90436a4e6@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1883#pullrequestreview-3183367176

From arapte at openjdk.org  Thu Sep  4 06:38:11 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 4 Sep 2025 06:38:11 GMT
Subject: [jfx25u] RFR: 8365859: Update copyright header for files modified in
 2025
Message-ID: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>

Update copyright year in files updated in the year 2025.

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

Commit messages:
 - 8365859: Update copyright header for files modified in 2025

Changes: https://git.openjdk.org/jfx25u/pull/10/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=10&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365859
  Stats: 48 lines in 48 files changed: 0 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jfx25u/pull/10.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/10/head:pull/10

PR: https://git.openjdk.org/jfx25u/pull/10

From arapte at openjdk.org  Thu Sep  4 06:38:11 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 4 Sep 2025 06:38:11 GMT
Subject: [jfx25u] RFR: 8365859: Update copyright header for files modified
 in 2025
In-Reply-To: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
References: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
Message-ID: <eA-6AsKGIdywIDQXRn7RKTzfgaEgwrVrUJIiH6xUYfc=.97f24c3b-725d-4b88-a8f8-810466be24d2@github.com>

On Thu, 4 Sep 2025 06:33:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in the year 2025.

@kevinrushforth Please take a look.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/10#issuecomment-3252132151

From jvos at openjdk.org  Thu Sep  4 11:38:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 4 Sep 2025 11:38:07 GMT
Subject: [jfx21u] RFR: 8366877: Change JavaFX release version to 21.0.9 in
 jfx21u
Message-ID: <CAeEGIqwbLQjJcJQOR8KNLoyeRumr2di_-4bFEXrdzI=.664f044a-b264-452d-923a-521c81748544@github.com>

Increase the version to 21.0.9

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

Commit messages:
 - Change version to 21.0.9

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

PR: https://git.openjdk.org/jfx21u/pull/101

From jvos at openjdk.org  Thu Sep  4 11:41:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 4 Sep 2025 11:41:08 GMT
Subject: [jfx17u] RFR: 8366876: Change JavaFX release version to 17.0.17 in
 jfx17u
Message-ID: <BkhgprsO5wytaiCrP0OWG4w2Sv3u2H1_G9fOvlW7XJg=.9f09a18d-2e89-4180-aeaa-0b1c62f7d002@github.com>

start work on 17.0.17

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

Commit messages:
 - Start work on 17.0.17

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

PR: https://git.openjdk.org/jfx17u/pull/238

From jpereda at openjdk.org  Thu Sep  4 11:44:58 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 4 Sep 2025 11:44:58 GMT
Subject: [jfx17u] RFR: 8366876: Change JavaFX release version to 17.0.17 in
 jfx17u
In-Reply-To: <BkhgprsO5wytaiCrP0OWG4w2Sv3u2H1_G9fOvlW7XJg=.9f09a18d-2e89-4180-aeaa-0b1c62f7d002@github.com>
References: <BkhgprsO5wytaiCrP0OWG4w2Sv3u2H1_G9fOvlW7XJg=.9f09a18d-2e89-4180-aeaa-0b1c62f7d002@github.com>
Message-ID: <vrQQxO3wIRpDA3hVtTcwaByDJaqvpKtgjaidF7PW3sg=.33061783-8297-47c6-899b-4dccca97498e@github.com>

On Thu, 4 Sep 2025 11:37:03 GMT, Johan Vos <jvos at openjdk.org> wrote:

> start work on 17.0.17

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/238#pullrequestreview-3184772456

From jpereda at openjdk.org  Thu Sep  4 11:44:58 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 4 Sep 2025 11:44:58 GMT
Subject: [jfx21u] RFR: 8366877: Change JavaFX release version to 21.0.9 in
 jfx21u
In-Reply-To: <CAeEGIqwbLQjJcJQOR8KNLoyeRumr2di_-4bFEXrdzI=.664f044a-b264-452d-923a-521c81748544@github.com>
References: <CAeEGIqwbLQjJcJQOR8KNLoyeRumr2di_-4bFEXrdzI=.664f044a-b264-452d-923a-521c81748544@github.com>
Message-ID: <9XwitYS-w1hlLB7L3QiK6WPBtn-i-1ifH8RrUZ2SO08=.2dfd8099-7f3b-49fd-9598-0d0bff729352@github.com>

On Thu, 4 Sep 2025 11:34:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase the version to 21.0.9

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/101#pullrequestreview-3184771451

From jvos at openjdk.org  Thu Sep  4 11:50:56 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 4 Sep 2025 11:50:56 GMT
Subject: [jfx17u] Integrated: 8366876: Change JavaFX release version to 17.0.17
 in jfx17u
In-Reply-To: <BkhgprsO5wytaiCrP0OWG4w2Sv3u2H1_G9fOvlW7XJg=.9f09a18d-2e89-4180-aeaa-0b1c62f7d002@github.com>
References: <BkhgprsO5wytaiCrP0OWG4w2Sv3u2H1_G9fOvlW7XJg=.9f09a18d-2e89-4180-aeaa-0b1c62f7d002@github.com>
Message-ID: <ErOPvfUylgO7uyQvWrWCNyIK6OBMhB6swjuhPRuDaL8=.64d8dfc9-7b9c-4408-af87-d60e4e878e3f@github.com>

On Thu, 4 Sep 2025 11:37:03 GMT, Johan Vos <jvos at openjdk.org> wrote:

> start work on 17.0.17

This pull request has now been integrated.

Changeset: ec7e3ba3
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/ec7e3ba31be2322521c104ccbe7b0d4fb334b8de
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8366876: Change JavaFX release version to 17.0.17 in jfx17u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx17u/pull/238

From jvos at openjdk.org  Thu Sep  4 11:51:50 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 4 Sep 2025 11:51:50 GMT
Subject: [jfx21u] Integrated: 8366877: Change JavaFX release version to 21.0.9
 in jfx21u
In-Reply-To: <CAeEGIqwbLQjJcJQOR8KNLoyeRumr2di_-4bFEXrdzI=.664f044a-b264-452d-923a-521c81748544@github.com>
References: <CAeEGIqwbLQjJcJQOR8KNLoyeRumr2di_-4bFEXrdzI=.664f044a-b264-452d-923a-521c81748544@github.com>
Message-ID: <L5ISirw4RSujGCWbsaRKklEC3Q0Zw5-XSJ3QTqA8I54=.acbe4d5a-4d31-4933-aac0-a582b41fb651@github.com>

On Thu, 4 Sep 2025 11:34:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase the version to 21.0.9

This pull request has now been integrated.

Changeset: 7613c1cf
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/7613c1cfcadbbb41aea7e4655c127c92225b54fd
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8366877: Change JavaFX release version to 21.0.9 in jfx21u

Reviewed-by: jpereda

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

PR: https://git.openjdk.org/jfx21u/pull/101

From duke at openjdk.org  Thu Sep  4 12:25:55 2025
From: duke at openjdk.org (danielpeintner)
Date: Thu, 4 Sep 2025 12:25:55 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <A6JJaqoFPa7_oVn9jdsGfvj4vzoa5ZEHnLKT_xCrVDw=.8137796a-f90a-4d58-8ebd-c8f3a58a1165@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

build.properties line 94:

> 92: jfx.build.jdk.buildnum=9
> 93: jfx.build.jdk.version.min=24
> 94: jfx.build.jdk.buildnum.min=36

Suggestion:

jfx.build.jdk.buildnum.min=38


Not 100% sure but I think the number should _increase_ and not _decrease_

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1883#discussion_r2321915857

From kcr at openjdk.org  Thu Sep  4 12:29:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Sep 2025 12:29:55 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <A6JJaqoFPa7_oVn9jdsGfvj4vzoa5ZEHnLKT_xCrVDw=.8137796a-f90a-4d58-8ebd-c8f3a58a1165@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
 <A6JJaqoFPa7_oVn9jdsGfvj4vzoa5ZEHnLKT_xCrVDw=.8137796a-f90a-4d58-8ebd-c8f3a58a1165@github.com>
Message-ID: <Tnlq9-bnA61MxhYpa6YZCKBlAXXIvvZeqF_Ady7Vvfw=.8c66869b-784c-4eb4-b2bc-86880c8fd11c@github.com>

On Thu, 4 Sep 2025 12:23:28 GMT, danielpeintner <duke at openjdk.org> wrote:

>> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
>> 
>> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
>> 
>> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
>> 
>> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.
>
> build.properties line 94:
> 
>> 92: jfx.build.jdk.buildnum=9
>> 93: jfx.build.jdk.version.min=24
>> 94: jfx.build.jdk.buildnum.min=36
> 
> Suggestion:
> 
> jfx.build.jdk.buildnum.min=38
> 
> 
> Not 100% sure but I think the number should _increase_ and not _decrease_

No. Build numbers are only meaningful within a specific release. JDK 23 GA was build 37 (jdk-23+37). JDK 24 GA was build 36 (jdk-24+36).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1883#discussion_r2321931310

From sykora at openjdk.org  Thu Sep  4 14:23:53 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 4 Sep 2025 14:23:53 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <89AxajCjADIbtVmzGomaEXef_1Ew-6ZQZF1WvB4zn5g=.9e584cc1-2414-47a6-9d64-5db701c085cd@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1883#pullrequestreview-3185596801

From kcr at openjdk.org  Thu Sep  4 15:14:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Sep 2025 15:14:50 GMT
Subject: [jfx25u] RFR: 8365859: Update copyright header for files modified
 in 2025
In-Reply-To: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
References: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
Message-ID: <aSz44vbz9du9Y7QXg1KlSEdAgcHCYZtq2jUlOiOMwAI=.49e1480d-8a83-4703-ad08-0dbf20649d59@github.com>

On Thu, 4 Sep 2025 06:33:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in the year 2025.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx25u/pull/10#pullrequestreview-3185813177

From martinfox656 at gmail.com  Thu Sep  4 15:14:51 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 4 Sep 2025 08:14:51 -0700
Subject: Invalid stage iconified coordinates on Windows
In-Reply-To: <e3ced1f9-d0fc-42a9-a374-754b0d7e3675@xpipe.io>
References: <e3ced1f9-d0fc-42a9-a374-754b0d7e3675@xpipe.io>
Message-ID: <6990E332-99B2-4DFA-BF9E-986C9E9FDED4@gmail.com>

Christopher,

This is a bug. If you hide a stage while iconified the position and size properties are updated to incorrect values. I?ll enter a bug report. The fix looks straightforward.

We shouldn?t send move and size notifications when an HWND is iconified since its rectangle contains useless coordinates. We check for this at various points but missed one (namely when processing WM_SHOWWINDOW).

Martin

> On Sep 2, 2025, at 2:08?PM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Hello,
> 
> I encountered an issue on Windows where the xProperty() and yProperty() of stages will be set to the special value -32000 when an iconified stage is closed. Simply calling .setIconified(true) on a stage and closing the window in the taskbar sends updates to any listeners with this value.
> 
> I understand that in the win32 API, this value is used to indicate that the window is iconified. But in my opinion the JavaFX state should not return that and instead keep the last x/y coordinates of where it was when it was iconified, so I assume that this is a bug.
> 
> In practice, this breaks various situations in which the application will store the last window coordinates for the next time it is opened. If the application is closed while the stage was iconified, the stage won't show again as it is off the screen.
> 
> This happens in the latest ea build.
> 
> Here is a reproducer:
> 
> public static void main(String[] args) {
>     Platform.startup(() -> {
>         var stage = new Stage();
>         stage.setWidth(500);
>         stage.setHeight(500);
>         stage.show();
>         stage.setIconified(true);
>         stage.xProperty().subscribe(number -> System.out.println(number));
>         stage.hide();
>         stage.show();
>     });
> }
> Best
> Christopher Schnick
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250904/03bb57cd/attachment.htm>

From angorya at openjdk.org  Thu Sep  4 15:23:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 4 Sep 2025 15:23:49 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
 [v2]
In-Reply-To: <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
 <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
Message-ID: <8sbhrLwTzTNReSNc0_UCSwEE2CZUw7HUj9_VfwX03ZU=.c335bca8-3f3e-4308-af35-aecd2a4d0009@github.com>

On Thu, 4 Sep 2025 01:54:26 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
>> 
>> Another option is to mark them as optional.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make OS-specific sources optional

This looks much safer and cleaner, thank you!

BTW, how could one change these option via UI?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1884#pullrequestreview-3185846227

From arapte at openjdk.org  Thu Sep  4 15:44:53 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 4 Sep 2025 15:44:53 GMT
Subject: [jfx25u] Integrated: 8365859: Update copyright header for files
 modified in 2025
In-Reply-To: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
References: <5RCJsT5f4SmNPB7yU9qzexfl1TQZiR3UDdsY28hoiOY=.2864e37f-2416-41f9-9cc6-2477f8007fbd@github.com>
Message-ID: <FSUr_MKz1qoqk-Hfh9_ox1Ird8V1PPFw5GUCq_e9fEU=.b21a0dbb-25c2-41d7-81b2-bc96e0cb220d@github.com>

On Thu, 4 Sep 2025 06:33:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in the year 2025.

This pull request has now been integrated.

Changeset: 62eeb404
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/62eeb404e741aed077f5d1bd0dc6f831a7bfa72f
Stats:     48 lines in 48 files changed: 0 ins; 0 del; 48 mod

8365859: Update copyright header for files modified in 2025

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx25u/pull/10

From nlisker at openjdk.org  Thu Sep  4 15:56:52 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 4 Sep 2025 15:56:52 GMT
Subject: RFR: 8366842: Update the classpath file of the graphics module
 [v2]
In-Reply-To: <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
References: <yd8QfQOzyyJ-FHVmjUa571JqkpC2qZFzMYPejZuwmBA=.c34102b6-2ccf-4264-8613-28fd090fde49@github.com>
 <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
Message-ID: <dXZsBZDErgN1v2YwL8jklbsqcxekENRv-QZZPsRvc7I=.a9313fcf-1da3-4351-aefd-fef6885f551e@github.com>

On Thu, 4 Sep 2025 01:54:26 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Removed the the directories under "build" from the sources list in Eclipse since they can be platform-specific or just irrelevant for almost all cases. Contributors can add them manually as needed.
>> 
>> Another option is to mark them as optional.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make OS-specific sources optional

<img width="932" height="547" alt="image" src="https://github.com/user-attachments/assets/53d8c614-e4b2-4bd9-9732-09baa64d603b" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1884#issuecomment-3254388926

From martinfox656 at gmail.com  Thu Sep  4 21:04:54 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 4 Sep 2025 14:04:54 -0700
Subject: Proposing an API for replacing the application menu on macOS
In-Reply-To: <CAJEpuXQtZMLowje=WvQFojFLdAut=MM2TF=qEQzMEPTLaG2=nw@mail.gmail.com>
References: <31E81814-652D-4741-9E0B-F89B6D5A90C3@gmail.com>
 <CAJEpuXQtZMLowje=WvQFojFLdAut=MM2TF=qEQzMEPTLaG2=nw@mail.gmail.com>
Message-ID: <F169B2F6-051D-4D06-9E93-9D7104F0EFFD@gmail.com>

I see your point. While working on this PR I noticed how much of the menu machinery lives in javafx.controls but doesn?t need to. Even the classes for building a menu could in theory live in javafx.graphics instead. Those classes don?t build controls, they build a menu model that?s used to drive controls. And the logic in MenuBarSkin that connects these models to the Toolkit doesn?t have much to do with the rest of the skin code. So I can imagine shuffling things around to get a menu API and system menu support into javafx.graphics.

I?m not convinced it would be worth the effort. In the end clients would still be building their menus using the same classes. The only API difference would be that the property that tracks the list of common system menus would be on, say, Application instead of MenuBar. I agree that?s the correct place but it would take a lot of API churn to get it there.

There?s another way to support third-party toolkits and that?s to get out of the way. The JavaFX application menu has some pretty severe limitations (it can?t be localized and Quit doesn?t work correctly for many apps) so clients have had to turn to third-party menu toolkits like NSMenuFX. That toolkit implements system menu support entirely outside of JavaFX using JNA. We could consider supporting this sort of toolkit by providing an API that explicitly disables the JavaFX system menu bar integration. There would be one remaining point of contact: glass would need to continue passing keyDown events to NSApp.mainMenu using performKeyEquivalent. This is not a big ask since glass has always done this and I see no reason why it shouldn?t continue doing so.

> On Sep 2, 2025, at 9:30?AM, Michael Strau? <michaelstrau2 at gmail.com> wrote:
> 
> This seems like a useful feature, but I have some comments on the
> proposed implementation.
> 
> JavaFX purposefully differentiates between the javafx.graphics and
> javafx.controls module. The javafx.graphics module is the core API,
> it's what users can't recreate themselves. These are not only JavaFX
> primitives like the scene graph, but also platform bindings.
> 
> The javafx.controls module, on the other hand, is _one_ implementation
> of a controls toolkit. Third-party developers should be able, in
> theory, to create their own controls toolkit with the APIs provided by
> javafx.graphics. Even if this is not actually done in practice, it is
> architecturally unsound to have javafx.graphics depend on
> javafx.controls, or to have controls interact with graphics in ways
> which can't be recreated by third-party developers.
> 
> System menu bars are one example of where javafx.controls is
> privileged, and your proposal would further cement this special
> status. What I think we should do instead is the following:
> 
> 1. Provide a core menu API in javafx.graphics
> 2. Have the menus in javafx.controls implement this core API
> 
> (Note that there already exists something resembling a core API for menus.)
> 
> This not only provides a well-defined API, but also allows us to take
> a new look at the implementation of an application menu. If the
> application menu is associated with the application instance, then
> maybe the Application class would be a more natural home for the app
> menu API instead of a static property on the MenuBar control.
> 
> 
> 
> On Tue, Sep 2, 2025 at 5:34?PM Martin Fox <martinfox656 at gmail.com> wrote:
>> 
>> I?ve submitted a draft PR (#1881) with an API that allows a JavaFX developer to replace the application menu on macOS. This is the first menu in the system menu bar, the one that is titled with the application?s name and sits next to the Apple menu. Currently JavaFX builds this menu internally and it?s not customizable in any way (it can?t even be localized). This menu used to require special handling at the OS level but those days are long gone so there?s no technical reason a developer can?t just replace it wholesale.
>> 
>> The implementation is more straightforward than the documentation. JavaFX has never documented the presence of this menu and it exhibits some unique behavior. The application menu is always present even for JavaFX applications that don?t use the system menu bar or MenuBars in general. And unlike other JavaFX menus the application menu is accessible when all windows are iconified. The application menu lives in a separate space from the per-window menus and we now need to document that.
>> 
>> The new API allows a developer to replace the application menu with a list of menus which I call the common menus. Like the current application menu the common menus are always present. Any menus provided by a MenuBar with setUseSystemMenu set to true will appear alongside the common menus. In theory a JavaFX developer could go full Mac-like and install a single set of common menus at application launch and forego per-window menus altogether. Or they could just replace the application menu and continue using per-window MenuBar?s in keeping with the JavaFX idiom.
>> 
>> The application menu contains some items which require platform support (Hide, Hide Others, and Show All) and I wasn?t sure where to put those calls. I?m still not sure. I welcome feedback on that and any other part of this proposed API.


From kcr at openjdk.org  Thu Sep  4 23:38:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Sep 2025 23:38:57 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <QKJx6nVAu5oZLMH7xPmQ2P5D4A6OrxJXLJ36f6Acuno=.60869a2e-d05a-4a07-916a-38f90191ce59@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

I plan to integrate this on Monday.

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

PR Comment: https://git.openjdk.org/jfx/pull/1883#issuecomment-3256331458

From kcr at openjdk.org  Fri Sep  5 14:53:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Sep 2025 14:53:20 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v4]
In-Reply-To: <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
Message-ID: <TJzAD60J8YWH0rp_uinffM5BZoYaAI_2txCyWzg-PdQ=.86260158-28b9-49c9-b838-525ac1a0637b@github.com>

On Sat, 30 Aug 2025 22:07:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

The API spec changes look good. I left a comment in the CSR that you need to add the changes made to `RadialGradient` (it looks good otherwise).

I spot checked the implementation and it all looks like what I expect. I'll finish reviewing and testing today.

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

PR Comment: https://git.openjdk.org/jfx/pull/1822#issuecomment-3258628251

From andy.goryachev at oracle.com  Fri Sep  5 15:09:39 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 5 Sep 2025 15:09:39 +0000
Subject: drag and drop
Message-ID: <CY8PR10MB72652E0C793BAA5B6D40F368E503A@CY8PR10MB7265.namprd10.prod.outlook.com>

Hi,

I've noticed a few issues and possible improvements in the area of drag and drop, I wanted to ask if anyone encountered these and whether they should be addressed.

1. DRAG_OVER event has its x/y coordinates hardcoded to 0.  (This looks like a bug, but perhaps it is a feature).

2. DragBoard.setDragView() seems to be autoscaling the images when they exceed some undocumented size.  There is no way to alter this behavior, such as set a different limit or disable the scaling altogether.

3. On DRAG_OVER, if the mouse release happens over a non-accepting target, the drag view image scuttles back to the point of origin.  This might be undesirable in some cases, but there is no API to disable the behavior.

What do you think?

-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250905/715b2420/attachment.htm>

From kcr at openjdk.org  Fri Sep  5 15:22:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Sep 2025 15:22:20 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v4]
In-Reply-To: <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <W3bZnixLx1y9pVjilCasz4gVXaD7xzZ96iyj5N1PyBc=.b2e41476-9775-4412-8090-65047cf3a50d@github.com>
Message-ID: <bUfd3SC7Bhf80-W1YiPb0lvxFys-51Wxo7lyXM3qeK4=.fd74a83d-f411-4832-9b27-fafc62ea67b5@github.com>

On Sat, 30 Aug 2025 22:07:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks good except for a typo in the manual test in two of the labels.

I'm running an automated headful test on macOS and Linux now and will approve when done (if no failures).

tests/manual/graphics/CssTransitionsTest.java line 121:

> 119:             new RectInfo("#rect4", "rect4", Color.WHITE),
> 120:             new RectInfo("#rect4", "rect5", Color.WHITE),
> 121:             new RectInfo("#rect5", "rect6", Color.WHITE));

Typo in the first string arg in the above two lines: they should be 5 and 6, respectively.

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

PR Review: https://git.openjdk.org/jfx/pull/1822#pullrequestreview-3189778842
PR Review Comment: https://git.openjdk.org/jfx/pull/1822#discussion_r2325376978

From mstrauss at openjdk.org  Fri Sep  5 15:41:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 5 Sep 2025 15:41:14 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v5]
In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
Message-ID: <cRdhq1JQTt-ES-BhXhptAbiyFvIfa6aKGq-ifBNfxKc=.6fe8d19d-05f2-437e-83ae-861a0f4c2e37@github.com>

> JavaFX unnecessarily restricts interpolation in the following ways:
> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
> 
> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
> 
> This PR includes the following changes:
> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
> 
> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1822/files
  - new: https://git.openjdk.org/jfx/pull/1822/files/a7aacb95..24d5afd4

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

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

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

From kcr at openjdk.org  Fri Sep  5 15:58:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Sep 2025 15:58:19 GMT
Subject: RFR: 8360940: Layout stops updating when using (public api)
 Parent#setNeedsLayout(true) due to incorrect state management
In-Reply-To: <qBa3rqWdnxHA7FYaTGqx5OelYTT2bzA53-JMUgmAzFg=.61fa75c5-95bb-42bd-8c1e-ca57c366d319@github.com>
References: <qBa3rqWdnxHA7FYaTGqx5OelYTT2bzA53-JMUgmAzFg=.61fa75c5-95bb-42bd-8c1e-ca57c366d319@github.com>
Message-ID: <0k9alp09IsIjR19fKEt8Ue56i0HXURNwnyPrRB7Swe8=.7ba4189c-a4e4-43b0-b7fe-09fb5ef06f76@github.com>

On Sat, 23 Aug 2025 14:58:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Ensures proper propagation of layout flags when using `forceParentLayout = true`.
> 
> This was the root cause of issue #1874
> 
> ### Note
> 
> Apparently it is still quite easy to mess up the layout flags. Basically, the layout flag tracked by Parent should always either be `CLEAN` for any scene graph branch, or `!CLEAN` + a layout pulse is scheduled on the corresponding `Scene`.
> 
> However, with careful use of the public API `requestLayout` one can get these flags in a bad state still:
> 
> Let's say I have a branch `A (root node under Scene) -> B -> C`, **and** a layout is in progress, **and** we're currently in the `layoutChildren` method of `C`. The flag `performingLayout` will be `true` for all nodes in the branch `A` ->  `B` -> `C`.  The `layout` method will set the layout flag to `CLEAN` as its first action, so when we're at `C::layoutChildren`, all flags have been reset to `CLEAN` already.  See the `Parent::layout` method for how all this works.
> 
> Now, to mess up the flags, all you need to do is call `requestLayout` on `B` or `C` from the `layoutChildren` of `C` (or indirectly by changing something and something is listening to this and schedules a layout on something somewhere in this branch); note that `requestLayout` is not documented to be illegal to call during layout, and some classes in FX will do so (ScrollPaneSkin, NumberAxis, etc..) risking the flags getting in a bad state... -- usually you get away with this, as there are many ways that layout is triggered, and eventually the flags will get overwritten and reset to a consistent state.
> 
> The bad state occurs because this code path is followed (all code from `Parent`):
> 
>     public void requestLayout() {
>         clearSizeCache();
>         markDirtyLayout(false, forceParentLayout);
>     }
>     
> Calls to `markDirtyLayout(false, false)`:
> 
>     private void markDirtyLayout(boolean local, boolean forceParentLayout) {
>         setLayoutFlag(LayoutFlags.NEEDS_LAYOUT);
>         if (local || layoutRoot) {
>             if (sceneRoot) {
>                 Toolkit.getToolkit().requestNextPulse();
>                 if (getSubScene() != null) {
>                     getSubScene().setDirtyLayout(this);
>                 }
>             } else {
>                 markDirtyLayoutBranch();
>             }
>         } else {
>             requestParentLayout(forceParentLayout);
>         }
>     }
>     
> Before going into the `else` (as none of the nodes is a layout root, and `local` was set to `false`) it will do **setLayoutFlag(LayoutFlags.NEEDS_LAYOUT)** ...

The fix looks correct. Can you provide an automated test?

I recommend removing `(public api)` from the title of the JBS bug and this PR -- we don't typically do that and it seems superfluous here.

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

PR Comment: https://git.openjdk.org/jfx/pull/1879#issuecomment-3258862425
PR Comment: https://git.openjdk.org/jfx/pull/1879#issuecomment-3258867305

From angorya at openjdk.org  Fri Sep  5 17:52:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 5 Sep 2025 17:52:24 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v5]
In-Reply-To: <cRdhq1JQTt-ES-BhXhptAbiyFvIfa6aKGq-ifBNfxKc=.6fe8d19d-05f2-437e-83ae-861a0f4c2e37@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <cRdhq1JQTt-ES-BhXhptAbiyFvIfa6aKGq-ifBNfxKc=.6fe8d19d-05f2-437e-83ae-861a0f4c2e37@github.com>
Message-ID: <ncNVy57eiIiYaJjStSL7ZjEUV-TFx70OTOIXuMP1NgQ=.aaabc2ce-627b-49ff-a096-61cf9e63ec04@github.com>

On Fri, 5 Sep 2025 15:41:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1822#pullrequestreview-3190306250

From kcr at openjdk.org  Fri Sep  5 18:02:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Sep 2025 18:02:22 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v5]
In-Reply-To: <cRdhq1JQTt-ES-BhXhptAbiyFvIfa6aKGq-ifBNfxKc=.6fe8d19d-05f2-437e-83ae-861a0f4c2e37@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
 <cRdhq1JQTt-ES-BhXhptAbiyFvIfa6aKGq-ifBNfxKc=.6fe8d19d-05f2-437e-83ae-861a0f4c2e37@github.com>
Message-ID: <4qDeX8O5Ao8y0PN17cDj-vc7TKLBg-YzyjPhiqDd5VU=.5411cd78-f9dd-4702-807e-dd97e5693c98@github.com>

On Fri, 5 Sep 2025 15:41:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> JavaFX unnecessarily restricts interpolation in the following ways:
>> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
>> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
>> 
>> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
>> 
>> This PR includes the following changes:
>> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
>> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
>> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
>> 
>> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
>> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Tests pass. All good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1822#pullrequestreview-3190330065

From mstrauss at openjdk.org  Fri Sep  5 18:15:09 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 5 Sep 2025 18:15:09 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v7]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <e34GTBnfz2fFDw-yjrI66YadLblhVo5XiON-zqlbx_M=.489d1558-0db1-46ba-829b-0448c0f8f585@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)

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

  whitespace, add final modifier

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/1c1c118d..c6ad3e32

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

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

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

From jvos at openjdk.org  Fri Sep  5 20:09:31 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 5 Sep 2025 20:09:31 GMT
Subject: [jfx21u] RFR: 8356982: Update WebKit to 622.1
Message-ID: <j_B3Oas_23s7_lpWrh1oz4IMyCTZDQbb1pMTIeHdQqM=.5acf37e6-03c8-4d7f-b8ac-e1347e90d762@github.com>

Hi all,

This pull request contains a backport of commit [4a8f3abc](https://github.com/openjdk/jfx/commit/4a8f3abc8ee665d1702df8d0bd63e9f663207ff1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

Changes: https://git.openjdk.org/jfx21u/pull/102/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8356982
  Stats: 725644 lines in 8650 files changed: 284002 ins; 364224 del; 77418 mod
  Patch: https://git.openjdk.org/jfx21u/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/102/head:pull/102

PR: https://git.openjdk.org/jfx21u/pull/102

From jpereda at openjdk.org  Fri Sep  5 20:20:16 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 5 Sep 2025 20:20:16 GMT
Subject: [jfx21u] RFR: 8356982: Update WebKit to 622.1
In-Reply-To: <j_B3Oas_23s7_lpWrh1oz4IMyCTZDQbb1pMTIeHdQqM=.5acf37e6-03c8-4d7f-b8ac-e1347e90d762@github.com>
References: <j_B3Oas_23s7_lpWrh1oz4IMyCTZDQbb1pMTIeHdQqM=.5acf37e6-03c8-4d7f-b8ac-e1347e90d762@github.com>
Message-ID: <pXlTPy8uBPPNQYLpxE9qpqbl_GBlub8Z4XllEjg-wWE=.377889d5-b0a3-4685-bc35-25c90c85c49f@github.com>

On Fri, 5 Sep 2025 20:00:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4a8f3abc](https://github.com/openjdk/jfx/commit/4a8f3abc8ee665d1702df8d0bd63e9f663207ff1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/102#pullrequestreview-3190674476

From jvos at openjdk.org  Fri Sep  5 20:36:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 5 Sep 2025 20:36:25 GMT
Subject: [jfx21u] Integrated: 8356982: Update WebKit to 622.1
In-Reply-To: <j_B3Oas_23s7_lpWrh1oz4IMyCTZDQbb1pMTIeHdQqM=.5acf37e6-03c8-4d7f-b8ac-e1347e90d762@github.com>
References: <j_B3Oas_23s7_lpWrh1oz4IMyCTZDQbb1pMTIeHdQqM=.5acf37e6-03c8-4d7f-b8ac-e1347e90d762@github.com>
Message-ID: <rX7o0wSX4IhYkKB2v4qNiKVEODsMZk0oTtweqfqaUgo=.814c5a12-15e6-4869-aaff-4a0b73366d6c@github.com>

On Fri, 5 Sep 2025 20:00:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4a8f3abc](https://github.com/openjdk/jfx/commit/4a8f3abc8ee665d1702df8d0bd63e9f663207ff1) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 239ad1a0
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/239ad1a089d8341b71ffb00189852036aa775df2
Stats:     725644 lines in 8650 files changed: 284002 ins; 364224 del; 77418 mod

8356982: Update WebKit to 622.1
8328684: HellowWebView demo crashes when a webpage is scrolled
8360270: Websocket communication issues with Vaadin applications through webview

Reviewed-by: jpereda
Backport-of: 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

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

PR: https://git.openjdk.org/jfx21u/pull/102

From jvos at openjdk.org  Sat Sep  6 08:31:37 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 6 Sep 2025 08:31:37 GMT
Subject: [jfx17u] RFR: 8356982: Update WebKit to 622.1
Message-ID: <5waJnqfz9a5O3okMUNbAUP4SnoxiUuo4n4e79IuzWD0=.ae378cbf-3896-4403-b548-d6568df9c68c@github.com>

Hi all,

This pull request contains a backport of commit 4a8f3abc from the openjdk/jfx repository.

The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

Changes: https://git.openjdk.org/jfx17u/pull/239/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8356982
  Stats: 725644 lines in 8650 files changed: 284002 ins; 364224 del; 77418 mod
  Patch: https://git.openjdk.org/jfx17u/pull/239.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/239/head:pull/239

PR: https://git.openjdk.org/jfx17u/pull/239

From jpereda at openjdk.org  Sat Sep  6 08:31:37 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Sat, 6 Sep 2025 08:31:37 GMT
Subject: [jfx17u] RFR: 8356982: Update WebKit to 622.1
In-Reply-To: <5waJnqfz9a5O3okMUNbAUP4SnoxiUuo4n4e79IuzWD0=.ae378cbf-3896-4403-b548-d6568df9c68c@github.com>
References: <5waJnqfz9a5O3okMUNbAUP4SnoxiUuo4n4e79IuzWD0=.ae378cbf-3896-4403-b548-d6568df9c68c@github.com>
Message-ID: <mK4OICvtT6ytrezGiL6Mr5SFWuENgDDXt2BITPqV5fo=.664fb4c8-f1f1-4b81-9062-627e30759f26@github.com>

On Sat, 6 Sep 2025 08:21:53 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 4a8f3abc from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/239#pullrequestreview-3191797158

From dhljfav at gmail.com  Sat Sep  6 14:21:14 2025
From: dhljfav at gmail.com (Juan Francisco Acosta Valenzuela)
Date: Sat, 6 Sep 2025 08:21:14 -0600
Subject: Saludos cordiales
Message-ID: <CAN3hAyJt0xVJ6CdNi_C0E-_qpfE7C5VSAAACB6Vy3GK-rPbz4w@mail.gmail.com>

, Les reenv?o la contrase?a que usare: Jhonny67%$&
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250906/801e8dea/attachment.htm>

From dhljfav at gmail.com  Sat Sep  6 18:31:10 2025
From: dhljfav at gmail.com (Juan Francisco Acosta Valenzuela)
Date: Sat, 6 Sep 2025 12:31:10 -0600
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
Message-ID: <CAN3hAy+9R_wbC1fdcBP5Fy4mjzqGvd12YcRpDoi-YYyHucwpDQ@mail.gmail.com>

Gracias por compartir esta propuesta, Nir.

La incorporaci?n de `MOUSE_DRAG_DONE` como tipo de evento parece ?til para
mejorar la trazabilidad de acciones de usuario en interfaces gr?ficas.
Desde una perspectiva institucional, este tipo de eventos puede facilitar
la auditor?a de interacciones en sistemas jur?dicos que requieren control
preciso de entrada de datos.

?Se ha considerado c?mo este evento se comportar?a en entornos con
dispositivos t?ctiles o h?bridos?

Saludos cordiales,
Lic. Juan Francisco Acosta Valenzuela
Internacional Pro-Derechos Humanos A.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250906/789faaa5/attachment-0001.htm>

From dhljfav at gmail.com  Sat Sep  6 18:32:59 2025
From: dhljfav at gmail.com (Juan Francisco Acosta Valenzuela)
Date: Sat, 6 Sep 2025 12:32:59 -0600
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
Message-ID: <CAN3hAyLW6vMHs62sST3TBcT8cDfHG0vGCN3TL9CXiezo6AEH0Q@mail.gmail.com>

Thank you for sharing this proposal, Nir.

The addition of `MOUSE_DRAG_DONE` as an event type seems valuable for
improving the traceability of user interactions in graphical interfaces.
>From an institutional perspective, such events can support audit trails in
legal systems that require precise input tracking.

Has consideration been given to how this event behaves in hybrid or
touch-based environments?

Best regards,
Lic. Juan Francisco Acosta Valenzuela
Internacional Pro-Derechos Humanos A.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250906/b68ed389/attachment.htm>

From dhljfav at gmail.com  Sat Sep  6 18:34:33 2025
From: dhljfav at gmail.com (Juan Francisco Acosta Valenzuela)
Date: Sat, 6 Sep 2025 12:34:33 -0600
Subject: No subject
Message-ID: <CAN3hAyLNtBWA5p1g-J80m0pSJCirB7-y60Qb6a9zyLjdHfR-bA@mail.gmail.com>

Thank you for sharing this proposal, Nir.

The addition of `MOUSE_DRAG_DONE` as an event type seems valuable for
improving the traceability of user interactions in graphical interfaces.
>From an institutional perspective, such events can support audit trails in
legal systems that require precise input tracking.

Has consideration been given to how this event behaves in hybrid or
touch-based environments?

Best regards,
Lic. Juan Francisco Acosta Valenzuela
Internacional Pro-Derechos Humanos A.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250906/f9400ca9/attachment.htm>

From michaelstrau2 at gmail.com  Sun Sep  7 00:17:02 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sun, 7 Sep 2025 02:17:02 +0200
Subject: Bulk change notifications for ObservableSet and ObservableMap
Message-ID: <CAJEpuXT26W5rjkY4QxHdY1PV_paNj+Ppsyiv+K3M9dFs2NDqsA@mail.gmail.com>

While a ListChangeListener can receive notifications for bulk
operations (addAll, removeAll, clear, etc.), SetChangeListener and
MapChangeListener only receive notifications for individual
add/replace/delete operations. For example, when mappings are added to
an ObservableMap with putAll(), listeners will be invoked once for
each individual mapping.

Since there is no way for a SetChangeListener/MapChangeListener to
know that more changes are coming, reacting to changes becomes
difficult and potentially inefficient if an expensive operation (like
reconfiguring the UI) is done for each individual change instead of
once for a bulk change operation.

I think we can improve the situation by adding a new method to
SetChangeListener.Change and MapChangeListener.Change:

  /**
   * Gets the next change in a series of changes.
   * <p>
   * Repeatedly calling this method allows a listener to fetch
   * all subsequent changes of a bulk set modification that would
   * otherwise be reported as repeated invocations of the listener.
   * <p>
   * After this method has been called, the current {@code Change}
   * instance is no longer valid and calling any method on it may
   * result in undefined behavior. Callers must not make any
   * assumptions about the identity of the {@code Change} instance
   * returned by this method; even if the returned instance is the
   * same as the current instance, it must be treated as a distinct
   * change.
   *
   * @return the next change, or {@code null} if there are
   *         no more changes
   */
  public Change<E> next() { return null; }


This new method allows listener implementations to fetch all
subsequent changes of a bulk operation, which can be implemented as
follows:

  set.addListener((SetChangeListener) change -> {
      do {
          // Inspect the change
          if (change.wasAdded()) {
              ...
          } else if (change.wasRemoved() {
              ...
          }
      } while ((change = change.next()) != null);
  }


The implementation is fully backwards-compatible for listeners that
are unaware of the new API. If the next() method is not called, then
all subsequent changes are delivered as usual by repeated listener
invocations.

If a listener only fetches some changes of a bulk operation (but stops
halfway through the operation), the remaining changes will also be
delivered with repeated listener invocations.

I've prepared a draft PR for this proposal:
https://github.com/openjdk/jfx/pull/1885

From hmeda at openjdk.org  Sun Sep  7 17:39:26 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Sun, 7 Sep 2025 17:39:26 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1
Message-ID: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>

Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.

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

Commit messages:
 - update license file for icu
 - white space correction
 - set U_HAVE_CHAR16_T flag to 0 for linux(same as mac and windows)
 - writeAssemblyCode should have same signature as before
 - resolve compilation error on windows
 - update cmake for icu77
 - update icu to v77.1

Changes: https://git.openjdk.org/jfx/pull/1882/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361644
  Stats: 71200 lines in 604 files changed: 48295 ins; 7306 del; 15599 mod
  Patch: https://git.openjdk.org/jfx/pull/1882.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1882/head:pull/1882

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

From kcr at openjdk.org  Sun Sep  7 17:39:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sun, 7 Sep 2025 17:39:26 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1
In-Reply-To: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
Message-ID: <4od2UKXn-U86Z4CmdOOXZqb1Q0EggU0y0yAh0jlyK5E=.4f203984-8c5b-43e1-b036-512be77a6466@github.com>

On Wed, 3 Sep 2025 11:21:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.

I think this can be taken out of Draft and made "rfr".

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1882#issuecomment-3262357914

From tsayao at openjdk.org  Sun Sep  7 18:30:32 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 7 Sep 2025 18:30:32 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v58]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <aMgRZB3Ob-QJbPc-Q-W3vwvGpwkQfaWQ_430rk4-EA4=.e37f9036-173c-4039-a7ed-27820f2ec493@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/ba33b9f8..aca72004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=57
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=56-57

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 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  Sun Sep  7 19:26:57 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 7 Sep 2025 19:26:57 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v59]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <UDw3dKnDAzEj0VmNUcxWoYO4ZDFcCx8GBqjUO7fz3jc=.aa6009c9-3f5d-4b6a-9438-14e9ab1a8e71@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Fix scene resize when window is unresizable

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/aca72004..c9d0c363

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=58
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=57-58

  Stats: 5 lines in 1 file changed: 5 ins; 0 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 jvos at openjdk.org  Mon Sep  8 07:52:27 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 8 Sep 2025 07:52:27 GMT
Subject: [jfx17u] Integrated: 8356982: Update WebKit to 622.1
In-Reply-To: <5waJnqfz9a5O3okMUNbAUP4SnoxiUuo4n4e79IuzWD0=.ae378cbf-3896-4403-b548-d6568df9c68c@github.com>
References: <5waJnqfz9a5O3okMUNbAUP4SnoxiUuo4n4e79IuzWD0=.ae378cbf-3896-4403-b548-d6568df9c68c@github.com>
Message-ID: <Ce3Quhcesg_iBqr5ITKjVmQ05m5tgJoMnw5zOuscIAo=.dd2fb461-1c44-433b-ae01-e9a55cc9ffb0@github.com>

On Sat, 6 Sep 2025 08:21:53 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 4a8f3abc from the openjdk/jfx repository.
> 
> The commit being backported was authored by Hima Bindu Meda on 13 Aug 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9f701b56
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/9f701b568e16f17e4456281a69eeb9e543037e54
Stats:     725644 lines in 8650 files changed: 284002 ins; 364224 del; 77418 mod

8356982: Update WebKit to 622.1
8328684: HellowWebView demo crashes when a webpage is scrolled
8360270: Websocket communication issues with Vaadin applications through webview

Reviewed-by: jpereda
Backport-of: 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

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

PR: https://git.openjdk.org/jfx17u/pull/239

From mhanl at openjdk.org  Mon Sep  8 09:15:21 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 8 Sep 2025 09:15:21 GMT
Subject: RFR: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <lTnxoqxCsPxINyvKdIKhiNlMnxw5oVeTA99IfJs0xhc=.d6a91a25-d0a1-4e3d-9b97-8a5fba4737c8@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

Nice step forward. Makes sense to also update the minimum required Gradle version.

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1883#pullrequestreview-3195659683

From hmeda at openjdk.org  Mon Sep  8 11:34:51 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 8 Sep 2025 11:34:51 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5
Message-ID: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>

Updated libxml2 to v2.14.5.
Verified build on all platforms. No issues seen

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

Commit messages:
 - whitespace correction
 - whitespace correction
 - white space correction
 - configure libxml on windows
 - update license file for libxml
 - configure libxml on linux
 - add missing files
 - update libxml to v2.14.5

Changes: https://git.openjdk.org/jfx/pull/1886/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361893
  Stats: 48058 lines in 103 files changed: 12675 ins; 14541 del; 20842 mod
  Patch: https://git.openjdk.org/jfx/pull/1886.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1886/head:pull/1886

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

From jvos at openjdk.org  Mon Sep  8 15:30:28 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 8 Sep 2025 15:30:28 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25 [v2]
In-Reply-To: <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
Message-ID: <5qU95-bukeyssScevoNhoM8nY2gYRz0-PP1S445MRBI=.53f2cf78-d5e4-4f4d-8c00-f6bb39407a85@github.com>

On Wed, 3 Sep 2025 17:09:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude more bugs that were both introduced and fixed in jfx25

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1871#pullrequestreview-3197046913

From kcr at openjdk.org  Mon Sep  8 15:30:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Sep 2025 15:30:28 GMT
Subject: RFR: 8365515: Create release notes for JavaFX 25 [v2]
In-Reply-To: <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
 <x60LNSzubeHxP7EOLS2fUwdgh5XCKeeaWHZ3x_emTtc=.11c4bca1-0287-47dc-a3f1-21c65be49e40@github.com>
Message-ID: <PsyZnDvwOJU7M-adJWjg5FXTmKy3CFiaFs6XcDRdJRc=.80119dd1-1b4d-4492-b6ef-c045cd2f4903@github.com>

On Wed, 3 Sep 2025 17:09:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 25:
>> 
>> https://bugs.openjdk.org/issues/?filter=47140
>> 
>> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude more bugs that were both introduced and fixed in jfx25

If there are no further comments, I will integrate this into `master` on Wednesday and then do the backport to `jfx25`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1871#issuecomment-3266837051

From kcr at openjdk.org  Mon Sep  8 21:11:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Sep 2025 21:11:18 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5
In-Reply-To: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
Message-ID: <EfZ08MIeL0q_2bjqc2RteiPdIr0A4gMs3qFzRQfwrvc=.d9bfa44d-547a-4039-b91d-c8fd3aec2d4b@github.com>

On Mon, 8 Sep 2025 11:16:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxml2 to v2.14.5.
> Verified build on all platforms. No issues seen

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1886#issuecomment-3268025753

From kcr at openjdk.org  Mon Sep  8 21:11:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Sep 2025 21:11:21 GMT
Subject: Integrated: 8365402: Bump minimum JDK version for JavaFX to JDK 24
In-Reply-To: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
References: <dvu3upd2ofEWJ0cKfWjo86r17R4Bsfft_XqrN53dEiM=.c8567162-19a3-4b53-b26e-574b19813649@github.com>
Message-ID: <Q3WAsoL82Rxb-TBwNQHsT5AVQOoh6N9CfZpiv-Hk58o=.b1696617-f239-46f1-a47f-55002392b1d5@github.com>

On Wed, 3 Sep 2025 18:37:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 24.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (24 in this specific case), is untested.
> 
> This PR targeted to JavaFX 26, and must not be backported to any earlier version. This needs a CSR and a release note.

This pull request has now been integrated.

Changeset: 9a4b601a
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9a4b601a7d3ea0ddfb001d27eecdc2ee4185298c
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8365402: Bump minimum JDK version for JavaFX to JDK 24

Reviewed-by: arapte, sykora, mhanl

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

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

From mstrauss at openjdk.org  Mon Sep  8 21:49:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 8 Sep 2025 21:49:21 GMT
Subject: Integrated: 8358820: Allow interpolation outside of range [0,1]
In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
Message-ID: <HFAhBtLQZgjpZ62M9zH6n-YqJMhz2W-seWdi4_6HjQE=.86ca2b20-f4c9-463b-8df8-00809f191b91@github.com>

On Fri, 6 Jun 2025 23:23:05 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> JavaFX unnecessarily restricts interpolation in the following ways:
> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
> 
> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
> 
> This PR includes the following changes:
> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
> 
> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>

This pull request has now been integrated.

Changeset: 999c396d
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/999c396d3c8d76be5b25c08e66490f026ae7b99a
Stats:     784 lines in 52 files changed: 533 ins; 33 del; 218 mod

8358820: Allow interpolation outside of range [0,1]

Reviewed-by: angorya, kcr

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

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

From angorya at openjdk.org  Mon Sep  8 23:43:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Sep 2025 23:43:38 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6
Message-ID: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>

Further additions to the MonkeyTester application:

- readme.md: 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`
- TableView page: canvas based cell and row factories
- Dialog page
- Progress Bar Page
- additional scripts in the WritingSystemsDemo
- pure Swing JTextField/JTextArea window
- ImageView page
- AudioClip page
- events in Drag and Drop page
- added miscellaneous options
- TextFlow page: updated hit info visualization, tab stop policy
- WebView page: added direct html input

Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

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

Commit messages:
 - Merge branch 'master' into 8353743.monkey
 - spelling
 - jdk jfx 24
 - whitespace
 - whitespace
 - sync up with standalone repo

Changes: https://git.openjdk.org/jfx/pull/1887/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353743
  Stats: 1915 lines in 45 files changed: 1496 ins; 140 del; 279 mod
  Patch: https://git.openjdk.org/jfx/pull/1887.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1887/head:pull/1887

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

From jdv at openjdk.org  Tue Sep  9 10:35:45 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 9 Sep 2025 10:35:45 GMT
Subject: RFR: 8356687: [TestBug] SWT tests do not run on macOS
Message-ID: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>

We have enabled swt tests under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) but they were disabled on macOS as they throw below exception :


FXCanvasScaledTest STANDARD_OUT
    ***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread

FXCanvasScaledTest > initializationError FAILED
    org.eclipse.swt.SWTException: Invalid thread access


Using `-XstartOnFirstThread` flag in gradle was not reliable and the issue was tracked under https://issues.gradle.org/browse/GRADLE-3290 and later under https://github.com/gradle/gradle/issues/864. This gradle issue is resolved and we can use `-XstartOnFirstThread` and enable SWT tests on macOS.

With `-XstartOnFirstThread`, SWT tests run fine on macOS.

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

Commit messages:
 - 8356687: [TestBug] SWT tests do not run on macOS

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

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

From kcr at openjdk.org  Tue Sep  9 15:21:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Sep 2025 15:21:31 GMT
Subject: [jfx25u] Integrated: 8366732: Change JavaFX release version to 25.0.2
 in jfx25u
In-Reply-To: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
References: <8TIFwJa9dp4djpY2CBlFHw26HipndhhfmjMAUbvVzGI=.734f6147-a009-417a-a7cb-941234d9cb4c@github.com>
Message-ID: <UDzk22FEZbPbQi_MCfYZJL9jGBrrEu0FIVUjlbd7Y_4=.a169cc19-0e5e-411f-856c-88a418cdfce5@github.com>

On Wed, 3 Sep 2025 17:08:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version to 25.0.2.
> 
> I will integrate this on Tuesday, Sep 9th, 2025 in the morning (Pacific).

This pull request has now been integrated.

Changeset: e87091aa
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/e87091aa5647363bece8b00690598486b711beb8
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8366732: Change JavaFX release version to 25.0.2 in jfx25u

Reviewed-by: jvos

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

PR: https://git.openjdk.org/jfx25u/pull/9

From kcr at openjdk.org  Tue Sep  9 16:38:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Sep 2025 16:38:50 GMT
Subject: RFR: 8356687: [TestBug] SWT tests do not run on macOS
In-Reply-To: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
References: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
Message-ID: <PfYYWx1tcyucsxe6jU_5mQwEc-sFGng_TTOpLaHlRn4=.6b2853e2-0b91-4ce8-a352-44fffc69d55d@github.com>

On Tue, 9 Sep 2025 10:30:12 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have enabled swt tests under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) but they were disabled on macOS as they throw below exception :
> 
> 
> FXCanvasScaledTest STANDARD_OUT
>     ***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread
> 
> FXCanvasScaledTest > initializationError FAILED
>     org.eclipse.swt.SWTException: Invalid thread access
> 
> 
> Using `-XstartOnFirstThread` flag in gradle was not reliable and the issue was tracked under https://issues.gradle.org/browse/GRADLE-3290 and later under https://github.com/gradle/gradle/issues/864. This gradle issue is resolved and we can use `-XstartOnFirstThread` and enable SWT tests on macOS.
> 
> With `-XstartOnFirstThread`, SWT tests run fine on macOS.

LGTM. I verified that the SWT tests fail on macOS before the fix and pass after the fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1888#pullrequestreview-3202423502

From angorya at openjdk.org  Tue Sep  9 16:43:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 9 Sep 2025 16:43:53 GMT
Subject: RFR: 8356687: [TestBug] SWT tests do not run on macOS
In-Reply-To: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
References: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
Message-ID: <Z7DJybz6o7jeqTSsHdYXiE9EVYrGGujenYyxXHrhJLY=.a11c0aa0-432c-455d-a9bb-49da71fa0f8f@github.com>

On Tue, 9 Sep 2025 10:30:12 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have enabled swt tests under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) but they were disabled on macOS as they throw below exception :
> 
> 
> FXCanvasScaledTest STANDARD_OUT
>     ***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread
> 
> FXCanvasScaledTest > initializationError FAILED
>     org.eclipse.swt.SWTException: Invalid thread access
> 
> 
> Using `-XstartOnFirstThread` flag in gradle was not reliable and the issue was tracked under https://issues.gradle.org/browse/GRADLE-3290 and later under https://github.com/gradle/gradle/issues/864. This gradle issue is resolved and we can use `-XstartOnFirstThread` and enable SWT tests on macOS.
> 
> With `-XstartOnFirstThread`, SWT tests run fine on macOS.

1 reviewer should be enough (thanks Kevin!)

but just in case, the code changes look good (I did not run the build).

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1888#pullrequestreview-3202437369

From mfox at openjdk.org  Tue Sep  9 18:47:50 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 9 Sep 2025 18:47:50 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding iconified
 stage
Message-ID: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>

When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.

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

Commit messages:
 - Added system test
 - Do not send size or position notifications when iconified

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

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

From kcr at openjdk.org  Tue Sep  9 20:25:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Sep 2025 20:25:50 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5
In-Reply-To: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
Message-ID: <rSE6KaH4i-yIPYhahzxtNMcc267A1Rki0qXzB2NiNKo=.e96be822-9da8-4dc1-b30d-c630e973705c@github.com>

On Mon, 8 Sep 2025 11:16:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxml2 to v2.14.5.
> Verified build on all platforms. No issues seen

Testing looks good. Code changes look good and match the upstream, although I noticed that there are two files that we have in our repo that are not in the upstream repo:

* `src/nanoftp.c` -- removed as part of this update (i.e., removed between `v2.13.8` and `v2.14.5`)
* `src/buf.h` -- removed a couple updates ago (it moved to `include/private/buf.h` between `v2.10.4` and `v2.12.6` so now we have two copies)

I recommend either removing them or filing a follow-up cleanup bug to do so.

I'll approve it as-is. If you decide to make changes I'll reapprove.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1886#pullrequestreview-3203162915

From mfox at openjdk.org  Tue Sep  9 20:26:17 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 9 Sep 2025 20:26:17 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage
In-Reply-To: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
Message-ID: <WbvQZ7ZlgrV9zNeured6-aaoL-vou_8oinvhqiHhc0c=.e42788f3-8f97-4d1d-baff-ed1abf3d1492@github.com>

On Tue, 9 Sep 2025 18:40:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.

I've disabled the system test on Linux. I've verified that the test passes with PR #1789.

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

PR Comment: https://git.openjdk.org/jfx/pull/1889#issuecomment-3272151159

From mfox at openjdk.org  Tue Sep  9 20:26:15 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 9 Sep 2025 20:26:15 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v2]
In-Reply-To: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
Message-ID: <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>

> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Disabled system test on Linux, DECORATED stage is changing height

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1889/files
  - new: https://git.openjdk.org/jfx/pull/1889/files/3fbfcef0..77135f53

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

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

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

From kcr at openjdk.org  Tue Sep  9 20:54:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 9 Sep 2025 20:54:14 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1
In-Reply-To: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
Message-ID: <skbNRhMqaeSkCC6lC0cEkmmPHOz7g8R0KV-jJU4b7R4=.7e1c68cc-aa1f-44da-86ef-0c5493b2e68e@github.com>

On Wed, 3 Sep 2025 11:21:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.

Looks good with one suggested change.

modules/javafx.web/src/main/native/Source/ThirdParty/icu/source/common/unicode/platform.h line 740:

> 738: #   else
> 739:         // conformant C11
> 740: #       define U_HAVE_CHAR16_T 0

Suggestion:

/* Commented out for JavaFX
        // conformant C11
#       define U_HAVE_CHAR16_T 1
*/
        // JavaFX: We cannot define U_HAVE_CHAR16_T
#       define U_HAVE_CHAR16_T 0


Since this alters upstream code, I recommend restoring line 740 from upstream (which sets `U_HAVE_CHAR16_T ` to 1), commenting it out, and adding a JavaFX-specific comment like the one I suggested above.

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

PR Review: https://git.openjdk.org/jfx/pull/1882#pullrequestreview-3203239751
PR Review Comment: https://git.openjdk.org/jfx/pull/1882#discussion_r2334737339

From mfox at openjdk.org  Tue Sep  9 21:31:51 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 9 Sep 2025 21:31:51 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v3]
In-Reply-To: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
Message-ID: <-LTxyevOPZAwNL7udRKok-sOUvzROZD1ULRm5FJ5geE=.c0c9ffbe-cb16-4dc5-812c-3e513bbd889f@github.com>

> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
> 
> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
> 
> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
> 
> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
> 
> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
> 
> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

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

 - Merge remote-tracking branch 'upstream/master' into sysmenuinplatform
 - Review feedback related to code consistency and clarity.
 - Merge remote-tracking branch 'upstream/master' into sysmenuinplatform
 - Merge branch 'sysmenuinplatform' of ssh://github.com/beldenfox/jfx into sysmenuinplatform
 - Cleanup and fixed a popup redirection bug.
 - Validating the system menu key event against the originating NSEvent before sending it to NSApp.mainMenu.
   Various bits of cleanup and correct handling of the popup redirector.
 - Merge remote-tracking branch 'upstream/master' into sysmenuinplatform
 - System menu accelerators triggered in scene graph but resolved in platform code

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

Changes: https://git.openjdk.org/jfx/pull/1848/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1848&range=02
  Stats: 201 lines in 12 files changed: 168 ins; 11 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1848.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1848/head:pull/1848

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

From jdv at openjdk.org  Wed Sep 10 04:38:34 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 10 Sep 2025 04:38:34 GMT
Subject: Integrated: 8356687: [TestBug] SWT tests do not run on macOS
In-Reply-To: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
References: <IWLlEzUiD4j385JTiQi86_5ap4AKc8O1sd0y4YLNUH4=.453e0eb2-613b-45d5-b2ac-a0aea9bc8b20@github.com>
Message-ID: <Au3SCKNlxjkMf3iR7VYReR1KA5RO-9J14a4leGDU9VU=.03768267-e3d0-4e55-a973-9064c8692860@github.com>

On Tue, 9 Sep 2025 10:30:12 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have enabled swt tests under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) but they were disabled on macOS as they throw below exception :
> 
> 
> FXCanvasScaledTest STANDARD_OUT
>     ***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread
> 
> FXCanvasScaledTest > initializationError FAILED
>     org.eclipse.swt.SWTException: Invalid thread access
> 
> 
> Using `-XstartOnFirstThread` flag in gradle was not reliable and the issue was tracked under https://issues.gradle.org/browse/GRADLE-3290 and later under https://github.com/gradle/gradle/issues/864. This gradle issue is resolved and we can use `-XstartOnFirstThread` and enable SWT tests on macOS.
> 
> With `-XstartOnFirstThread`, SWT tests run fine on macOS.

This pull request has now been integrated.

Changeset: 682d7682
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/682d768244f1d290f0a7625437b0e72e74aae365
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8356687: [TestBug] SWT tests do not run on macOS

Reviewed-by: kcr, angorya

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

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

From crschnick at xpipe.io  Wed Sep 10 08:13:53 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 10 Sep 2025 10:13:53 +0200
Subject: macOS 26 platform preferences
Message-ID: <b99880ca-6a5a-47e3-82f7-4730d76f657d@xpipe.io>

Hello,

With the release of macOS 26 coming up, I just wanted to say that I have 
been running it the last few weeks without much issues with JavaFX 
applications.

The only thing I noticed is that the accent color platform preference 
somehow does not update on a settings change. The light/dark mode 
setting does update though.

It would also be nice to have access to the new icon/widget style 
property in the platform preferences. That way, the application can 
update its own icons in addition to the .app icon, like in here: 
https://www.reddit.com/r/JavaFX/comments/1lo4at8/macos_26_dynamic_dock_icon_style_with_a_javafx/

Best
Christopher Schnick


From jdv at openjdk.org  Wed Sep 10 10:01:50 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 10 Sep 2025 10:01:50 GMT
Subject: RFR: 8356688: [TestBug] SWT tests fail on some Linux distros
Message-ID: <hn1xDTYXl-Xalnh0dg1yMM9hV1_LP8lg2RVGQZxj4P8=.6d02c26d-f728-43b7-bc6c-6d11fc31137d@github.com>

SWT unit tests were not enabled under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) as it resulted in crash. We forced x11 as GDK backend under [JDK-8210411](https://bugs.openjdk.org/browse/JDK-8210411) but this is not sufficient in case where FXCanvas is embedded in an SWT window as captured at : https://github.com/openjdk/jfx/pull/1783#issuecomment-2844889943

Setting the environment variable in :swt:test gradle task fixes the issue. This is verified in Ubuntu 22.04 and 24.04 and swt tests run fine.

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

Commit messages:
 - Don't fix 8340378 in this PR
 - Update comment
 - Set GDK_BACKEND as x11 in Linux

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

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

From arapte at openjdk.org  Wed Sep 10 11:33:16 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 10 Sep 2025 11:33:16 GMT
Subject: RFR: 8367306: HeaderButtonOverlayTest fails to compile with
 TEST_SDK_PATH
Message-ID: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>

When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: _package com.sun.glass.events is not visible_

The test compiles and executes fine with normal command: `gradle :graphics:test`.
In this case the JavaFX is built locally and the `com.sun.glass.events.MouseEvent` class file becomes reachable through classpath. A bug is filed to investigate this separately : [JDK-8367327](https://bugs.openjdk.org/browse/JDK-8367327)

Fix is quick, to update the `modules/javafx.graphics/src/test/addExports`.

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

Commit messages:
 - 8367306: HeaderButtonOverlayTest fails to compile with TEST_SDK_PATH

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

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

From arapte at openjdk.org  Wed Sep 10 11:33:17 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 10 Sep 2025 11:33:17 GMT
Subject: RFR: 8367306: HeaderButtonOverlayTest fails to compile with
 TEST_SDK_PATH
In-Reply-To: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
References: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
Message-ID: <IMnhVlXvxZBgWCRMyH8m4pbfC_0yWeQ8BVKVYgvrrYE=.f948c17e-e017-4b6f-8aa3-00bde2e4c329@github.com>

On Wed, 10 Sep 2025 11:26:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: _package com.sun.glass.events is not visible_
> 
> The test compiles and executes fine with normal command: `gradle :graphics:test`.
> In this case the JavaFX is built locally and the `com.sun.glass.events.MouseEvent` class file becomes reachable through classpath. A bug is filed to investigate this separately : [JDK-8367327](https://bugs.openjdk.org/browse/JDK-8367327)
> 
> Fix is quick, to update the `modules/javafx.graphics/src/test/addExports`.

@kevinrushforth please take a look

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

PR Comment: https://git.openjdk.org/jfx/pull/1891#issuecomment-3274529637

From kcr at openjdk.org  Wed Sep 10 12:06:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 12:06:59 GMT
Subject: RFR: 8367306: HeaderButtonOverlayTest fails to compile with
 TEST_SDK_PATH
In-Reply-To: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
References: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
Message-ID: <ImFONbltpDxlTKPkDBYaFmglOyYhyosq5JOrigdPpA8=.687b3d1b-05c9-4b4c-8ea9-65b326f96f3f@github.com>

On Wed, 10 Sep 2025 11:26:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: _package com.sun.glass.events is not visible_
> 
> The test compiles and executes fine with normal command: `gradle :graphics:test`.
> In this case the JavaFX is built locally and the `com.sun.glass.events.MouseEvent` class file becomes reachable through classpath. A bug is filed to investigate this separately : [JDK-8367327](https://bugs.openjdk.org/browse/JDK-8367327)
> 
> Fix is quick, to update the `modules/javafx.graphics/src/test/addExports`.

Good catch. This is an obviously correct fix.

As noted, the reason this wasn't caught earlier is that due to [JDK-8367327](https://bugs.openjdk.org/browse/JDK-8367327), tests accessing internal packages will compile even without the package being exported in the `addExports` files. It won't be available at runtime, but since `HeaderButtonOverlayTest` only uses static constants that are resolved at compile-time, it didn't actually try to load a class from that package at runtime.

Given that this is a trivially correct test-only fix, a single reviewer is sufficient and there is no need to wait for 24 hours.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1891#pullrequestreview-3205835871

From arapte at openjdk.org  Wed Sep 10 12:10:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 10 Sep 2025 12:10:50 GMT
Subject: Integrated: 8367306: HeaderButtonOverlayTest fails to compile with
 TEST_SDK_PATH
In-Reply-To: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
References: <sqX_UMRywNAmM9adcMCTaRcnC6hjuH50jSIw-tuaRAk=.4712b535-c579-4df3-928b-5f0dd57556a8@github.com>
Message-ID: <m_SHe9eV0fjPgifdtaFPTmc6SXbVQW5tn8dJL-c5lMo=.b2d0e49e-9a59-44a1-aed3-df354534e262@github.com>

On Wed, 10 Sep 2025 11:26:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> When using `-PTEST_SDK_PATH=<path>` and `-PTEST_ONLY=true`, the test `HeaderButtonOverlayTest` fails to compile with error: _package com.sun.glass.events is not visible_
> 
> The test compiles and executes fine with normal command: `gradle :graphics:test`.
> In this case the JavaFX is built locally and the `com.sun.glass.events.MouseEvent` class file becomes reachable through classpath. A bug is filed to investigate this separately : [JDK-8367327](https://bugs.openjdk.org/browse/JDK-8367327)
> 
> Fix is quick, to update the `modules/javafx.graphics/src/test/addExports`.

This pull request has now been integrated.

Changeset: 3e376e66
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3e376e66a3510f8dee7abb52344961caee1d114a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8367306: HeaderButtonOverlayTest fails to compile with TEST_SDK_PATH

Reviewed-by: kcr

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

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

From tsayao at openjdk.org  Wed Sep 10 13:31:19 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 10 Sep 2025 13:31:19 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v60]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits:

 - Merge branch 'master' into 8354943
 - - Fix scene resize when window is unresizable
 - - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view
 - - Fix tests
 - - Fix FOCUS_LOST begin sent on focused windows
 - - Remove CenterOnScreenTest.java
 - Merge branch 'master' into 8354943
 - - Fix (SetSceneScalingTest)
 - - Fix mistake (assertTrue -> assumeTrue)
 - - Add hint about macOS beeps
   - Disable some tests on specific platforms
 - ... and 63 more: https://git.openjdk.org/jfx/compare/3e376e66...8bc6c4b6

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=59
  Stats: 4131 lines in 27 files changed: 2732 ins; 770 del; 629 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  Wed Sep 10 13:39:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 13:39:23 GMT
Subject: Integrated: 8365515: Create release notes for JavaFX 25
In-Reply-To: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
References: <v_Iu3gPNqURoGwDJB-4rnvFlQQtayBhdNlLx4OP9CB8=.bd5aa25c-373e-4113-b17d-8d0b5356c299@github.com>
Message-ID: <hippxYKN18qP7ehnTZw6bI44k7xKXD6nC6rdi2vQHu4=.e5165f63-3b25-4eec-a350-dc425d83099b@github.com>

On Fri, 15 Aug 2025 18:08:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 25 release. This will first go into master, and then be backported to the jfx25 branch so it will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 25:
> 
> https://bugs.openjdk.org/issues/?filter=47140
> 
> Additionally, we had four issues with a `release-note=yes` label, which are included in the list of important changes, etc.

This pull request has now been integrated.

Changeset: 09ff1259
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/09ff1259994e64efd055d22572e3da2e291c7a2d
Stats:     150 lines in 1 file changed: 150 ins; 0 del; 0 mod

8365515: Create release notes for JavaFX 25

Reviewed-by: angorya, jvos, mstrauss

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

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

From kcr at openjdk.org  Wed Sep 10 14:14:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 14:14:37 GMT
Subject: [jfx25] RFR: 8365515: Create release notes for JavaFX 25
Message-ID: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>

Clean backport of the JavaFX 25 release notes to the jfx25 stabilization branch, so they will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).

NOTE: The release notes are not part of the build, so this backport to jfx25 will not cause a respin of JavaFX 25.

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

Commit messages:
 - Backport 09ff1259994e64efd055d22572e3da2e291c7a2d

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

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

From kcr at openjdk.org  Wed Sep 10 14:14:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 14:14:37 GMT
Subject: [jfx25] RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
References: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
Message-ID: <MOSDV1hDlp2e_Wgb_TkG-i-r2G6Z2fvNm2M_rgFCvAo=.1bbdc8d4-337f-4fdd-b4ea-44f95e840468@github.com>

On Wed, 10 Sep 2025 14:05:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 25 release notes to the jfx25 stabilization branch, so they will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx25 will not cause a respin of JavaFX 25.

Reviewer: @andy-goryachev-oracle or @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1892#issuecomment-3275169280

From angorya at openjdk.org  Wed Sep 10 14:20:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Sep 2025 14:20:57 GMT
Subject: [jfx25] RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
References: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
Message-ID: <GsfQW0dIap_aqtO9Nw2sMFPSP7EthGgOqRkIyZ2kdkU=.12b94dec-5b8a-46e7-ae71-01674b1d6a40@github.com>

On Wed, 10 Sep 2025 14:05:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 25 release notes to the jfx25 stabilization branch, so they will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx25 will not cause a respin of JavaFX 25.

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1892#pullrequestreview-3206405291

From jvos at openjdk.org  Wed Sep 10 14:50:39 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 10 Sep 2025 14:50:39 GMT
Subject: [jfx25] RFR: 8365515: Create release notes for JavaFX 25
In-Reply-To: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
References: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
Message-ID: <3OVWmc542aqDJJ8j2KCD6r61SqGYOUoep_OkssO38i8=.6090187b-d58b-4b8e-9753-c51cbfa88b2e@github.com>

On Wed, 10 Sep 2025 14:05:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 25 release notes to the jfx25 stabilization branch, so they will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx25 will not cause a respin of JavaFX 25.

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1892#pullrequestreview-3206535157

From kcr at openjdk.org  Wed Sep 10 15:14:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 15:14:56 GMT
Subject: [jfx25] Integrated: 8365515: Create release notes for JavaFX 25
In-Reply-To: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
References: <doSkyeMCTVCCIm7KV7fT6MeWlFKmpjcyFIIbj9D1GiY=.49437f98-e374-42b8-88e5-bcb834256198@github.com>
Message-ID: <x5SOyYOZDIKD74MvPbDQC9WUKXpA4ziVAED8kwbb8yc=.da5393c7-c65c-4ce5-b341-85c11ef537a0@github.com>

On Wed, 10 Sep 2025 14:05:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 25 release notes to the jfx25 stabilization branch, so they will be available in that branch when JavaFX 25 is published (and from there also synced into the jfx25u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx25 will not cause a respin of JavaFX 25.

This pull request has now been integrated.

Changeset: 95086967
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/95086967107bababfe5e34df4ca1f6c422cc515c
Stats:     150 lines in 1 file changed: 150 ins; 0 del; 0 mod

8365515: Create release notes for JavaFX 25

Reviewed-by: angorya, jvos
Backport-of: 09ff1259994e64efd055d22572e3da2e291c7a2d

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

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

From lkostyra at openjdk.org  Wed Sep 10 15:46:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 10 Sep 2025 15:46:53 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v60]
In-Reply-To: <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@github.com>
Message-ID: <hVHQezNT5ebKI_KV8finuSGLZRmYom-BB0UMIuo3G70=.715cf799-86fb-4c1e-86d1-314ebfd62a9c@github.com>

On Wed, 10 Sep 2025 13:31:19 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.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits:
> 
>  - Merge branch 'master' into 8354943
>  - - Fix scene resize when window is unresizable
>  - - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view
>  - - Fix tests
>  - - Fix FOCUS_LOST begin sent on focused windows
>  - - Remove CenterOnScreenTest.java
>  - Merge branch 'master' into 8354943
>  - - Fix (SetSceneScalingTest)
>  - - Fix mistake (assertTrue -> assumeTrue)
>  - - Add hint about macOS beeps
>    - Disable some tests on specific platforms
>  - ... and 63 more: https://git.openjdk.org/jfx/compare/3e376e66...8bc6c4b6

I've been going through the review and tests here, I still have some more code to review but I did notice there are some test failures on Windows:

StageOwnershipTest. openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle, Modality) [3] UNDECORATED, APPLICATION_MODAL
StageOwnershipTest. openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle, Modality) [4] UNDECORATED, WINDOW_MODAL
StageOwnershipTest. openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle, Modality) [5] EXTENDED, APPLICATION_MODAL
StageOwnershipTest. openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle, Modality) [6] EXTENDED, WINDOW_MODAL
StageOwnershipTest. openingModalChildStageWhileMaximizedShouldNotUnmaximize(StageStyle, Modality) [3] UNDECORATED, APPLICATION_MODAL
StageOwnershipTest. openingModalChildStageWhileMaximizedShouldNotUnmaximize(StageStyle, Modality) [4] UNDECORATED, WINDOW_MODAL
StageOwnershipTest. openingModalChildStageWhileMaximizedShouldNotUnmaximize(StageStyle, Modality) [5] EXTENDED, APPLICATION_MODAL
StageOwnershipTest. openingModalChildStageWhileMaximizedShouldNotUnmaximize(StageStyle, Modality) [6] EXTENDED, WINDOW_MODAL 


One StageOwnershipTest - `iconifyParentShouldHideChildren [DECORATED]` - also consistently fails on my Ubuntu 24.04.2 VM.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3275531952

From duke at openjdk.org  Wed Sep 10 16:49:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Sep 2025 16:49:13 GMT
Subject: Withdrawn: 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: <pIdj9vcnZgQRWrfLKWkbwbyEQVXKUTlBlEBc9R2Uz8s=.e101949d-113f-452a-b461-30336730edba@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()"

This pull request has been closed without being integrated.

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

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

From mfox at openjdk.org  Wed Sep 10 18:43:17 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 10 Sep 2025 18:43:17 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: <0gNgRbGpbITe31QNWxaYjv3FjQPQEbsgeKe1ZaEJt5I=.be2394a9-e45a-4671-a231-c5f79e6f4aa4@github.com>
References: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
 <0gNgRbGpbITe31QNWxaYjv3FjQPQEbsgeKe1ZaEJt5I=.be2394a9-e45a-4671-a231-c5f79e6f4aa4@github.com>
Message-ID: <qI5YFljEuOm5Xs1OsXHUSukhK91U0ANvqpsXIgP0mlc=.c19e13d4-1593-42ba-8f71-fe01ddd4c7df@github.com>

On Sun, 31 Aug 2025 07:36:28 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX.
>> 
>> The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method.
>> 
>> The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus.
>> 
>> I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it worked without any errors, but on further testing I noticed some issues with the menu bar. I am currently writing the test and fixes for it.
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

Using osascript to check the state of the menus is a great idea (assuming there's no policy against using that sort of thing in the system tests). Far better than what I did in PR #1881.

You need to have folks on the AWT/Swift side review this new approach. If I understand this correctly when the JavaFX window assumes focus you're stashing away NSApp.mainMenu under the assumption that it was put there by AWT. Then you're replacing it with an NSMenu built by JavaFX. When the JavaFX window loses focus you're putting the stashed AWT NSMenu back into NSApp.mainMenu. The two big questions are:

a) Will AWT malfunction since NSApp.mainMenu no longer points to the NSMenu they expect?
b) During the period of time the JavaFX window has focus is there some chance AWT will change NSApp.mainMenu out from under us?

Put another way, JavaFX currently uses window focus to figure out which window should "own" NSApp.mainMenu and this PR extends that notion to include Swing windows. I'm not sure that's matches how AWT works internally so someone on the AWT side needs to weigh in.

What you're doing on the JavaFX side is just some pointer shuffling. Swapping NSApp.mainMenu in and out makes me uneasy but it's hard for me to point to a specific problem that will arise on the JavaFX side.

There's also the larger question of whether we want to support this configuration to begin with.

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

PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-3276107668

From martinfox656 at gmail.com  Wed Sep 10 19:25:20 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 10 Sep 2025 12:25:20 -0700
Subject: macOS 26 platform preferences
In-Reply-To: <b99880ca-6a5a-47e3-82f7-4730d76f657d@xpipe.io>
References: <b99880ca-6a5a-47e3-82f7-4730d76f657d@xpipe.io>
Message-ID: <2F09AF9E-57F0-4E72-A9F6-C6385345FB33@gmail.com>

Christopher,

I?ve filed https://bugs.openjdk.org/browse/JDK-8367370 for the accent color problem.

Martin

> On Sep 10, 2025, at 1:13?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Hello,
> 
> With the release of macOS 26 coming up, I just wanted to say that I have been running it the last few weeks without much issues with JavaFX applications.
> 
> The only thing I noticed is that the accent color platform preference somehow does not update on a settings change. The light/dark mode setting does update though.
> 
> It would also be nice to have access to the new icon/widget style property in the platform preferences. That way, the application can update its own icons in addition to the .app icon, like in here: https://www.reddit.com/r/JavaFX/comments/1lo4at8/macos_26_dynamic_dock_icon_style_with_a_javafx/
> 
> Best
> Christopher Schnick
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250910/14ca6750/attachment.htm>

From kcr at openjdk.org  Wed Sep 10 19:26:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 19:26:15 GMT
Subject: RFR: 8356688: [TestBug] SWT tests fail on some Linux distros
In-Reply-To: <hn1xDTYXl-Xalnh0dg1yMM9hV1_LP8lg2RVGQZxj4P8=.6d02c26d-f728-43b7-bc6c-6d11fc31137d@github.com>
References: <hn1xDTYXl-Xalnh0dg1yMM9hV1_LP8lg2RVGQZxj4P8=.6d02c26d-f728-43b7-bc6c-6d11fc31137d@github.com>
Message-ID: <I7M2Q3Pu4Ghg03InHE8jYS1XNiEVYTtcHMK_LqwDlxQ=.f83294c1-c579-46f9-bea4-3a08e9502237@github.com>

On Wed, 10 Sep 2025 09:56:24 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SWT unit tests were not enabled under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) as it resulted in crash. We forced x11 as GDK backend under [JDK-8210411](https://bugs.openjdk.org/browse/JDK-8210411) but this is not sufficient in case where FXCanvas is embedded in an SWT window as captured at : https://github.com/openjdk/jfx/pull/1783#issuecomment-2844889943
> 
> Setting the environment variable in :swt:test gradle task fixes the issue. This is verified in Ubuntu 22.04 and 24.04 and swt tests run fine.

Looks good. I ran the tests on a couple additional Linux systems and the tests passed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1890#pullrequestreview-3207530665

From andy.goryachev at oracle.com  Wed Sep 10 19:45:36 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 10 Sep 2025 19:45:36 +0000
Subject: macOS 26 platform preferences
In-Reply-To: <2F09AF9E-57F0-4E72-A9F6-C6385345FB33@gmail.com>
References: <b99880ca-6a5a-47e3-82f7-4730d76f657d@xpipe.io>
 <2F09AF9E-57F0-4E72-A9F6-C6385345FB33@gmail.com>
Message-ID: <CY8PR10MB7265786889D3528A42619267E50EA@CY8PR10MB7265.namprd10.prod.outlook.com>

Thank you, Martin.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com>
Date: Wednesday, September 10, 2025 at 12:26
To: Christopher Schnick <crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: macOS 26 platform preferences

Christopher,

I?ve filed https://bugs.openjdk.org/browse/JDK-8367370 for the accent color problem.

Martin

On Sep 10, 2025, at 1:13?AM, Christopher Schnick <crschnick at xpipe.io> wrote:

Hello,

With the release of macOS 26 coming up, I just wanted to say that I have been running it the last few weeks without much issues with JavaFX applications.

The only thing I noticed is that the accent color platform preference somehow does not update on a settings change. The light/dark mode setting does update though.

It would also be nice to have access to the new icon/widget style property in the platform preferences. That way, the application can update its own icons in addition to the .app icon, like in here: https://www.reddit.com/r/JavaFX/comments/1lo4at8/macos_26_dynamic_dock_icon_style_with_a_javafx/

Best
Christopher Schnick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250910/f7603886/attachment.htm>

From zelmidaoui at openjdk.org  Wed Sep 10 21:07:45 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 10 Sep 2025 21:07:45 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
Message-ID: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>

The test seems to be working in Linux currently, so I enabled it for Linux systems.

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

Commit messages:
 - Removed unused imports
 - Update ContextMenuNPETest.java
 - Added testWatcher and enabled test for Linux systems
 - Merge branch 'openjdk:master' into 8321625.ContextMenuNPETest
 - test issue

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

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

From kcr at openjdk.org  Wed Sep 10 21:07:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 21:07:48 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
Message-ID: <8ry8j02tBJ7bICioA1mfnV6szU1hNbz0e1G2kEhFMg0=.75b90d34-228b-46e4-870c-c2be78ef01d7@github.com>

On Wed, 10 Sep 2025 14:43:11 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The test seems to be working in Linux currently, so I enabled it for Linux systems.

tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 48:

> 46: import org.junit.jupiter.api.Test;
> 47: import org.junit.jupiter.api.extension.ExtendWith;
> 48: import test.util.ScreenCaptureTestWatcher;

You can remove these now-unused imports

tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 64:

> 62:  */
> 63: 
> 64: @ExtendWith(ScreenCaptureTestWatcher.class)

`ScreenCaptureTestWatcher` is only intended to be used with developer builds. We must not integrate a test into the repo with it enabled.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337353860
PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337076924

From zelmidaoui at openjdk.org  Wed Sep 10 21:07:48 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 10 Sep 2025 21:07:48 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <8ry8j02tBJ7bICioA1mfnV6szU1hNbz0e1G2kEhFMg0=.75b90d34-228b-46e4-870c-c2be78ef01d7@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <8ry8j02tBJ7bICioA1mfnV6szU1hNbz0e1G2kEhFMg0=.75b90d34-228b-46e4-870c-c2be78ef01d7@github.com>
Message-ID: <ULyWvTVrFEGgesp6phD9uMwqUKcHJIcEx3Z8LtkljcA=.81454fc7-441f-475a-b042-90c2e5f3ea92@github.com>

On Wed, 10 Sep 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The test seems to be working in Linux currently, so I enabled it for Linux systems.
>
> tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 48:
> 
>> 46: import org.junit.jupiter.api.Test;
>> 47: import org.junit.jupiter.api.extension.ExtendWith;
>> 48: import test.util.ScreenCaptureTestWatcher;
> 
> You can remove these now-unused imports

Done

> tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 64:
> 
>> 62:  */
>> 63: 
>> 64: @ExtendWith(ScreenCaptureTestWatcher.class)
> 
> `ScreenCaptureTestWatcher` is only intended to be used with developer builds. We must not integrate a test into the repo with it enabled.

I updated it and removed the `ScreenCaptureTestWatcher`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337907764
PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337170383

From angorya at openjdk.org  Wed Sep 10 21:20:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Sep 2025 21:20:18 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <ULyWvTVrFEGgesp6phD9uMwqUKcHJIcEx3Z8LtkljcA=.81454fc7-441f-475a-b042-90c2e5f3ea92@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <8ry8j02tBJ7bICioA1mfnV6szU1hNbz0e1G2kEhFMg0=.75b90d34-228b-46e4-870c-c2be78ef01d7@github.com>
 <ULyWvTVrFEGgesp6phD9uMwqUKcHJIcEx3Z8LtkljcA=.81454fc7-441f-475a-b042-90c2e5f3ea92@github.com>
Message-ID: <pNCyqCSlcuuxVw_OM3iTQdZjaciQruOo3UQM0A9QDio=.7b29eecb-ec21-473d-8f8b-7baacd7b52e5@github.com>

On Wed, 10 Sep 2025 15:37:32 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 64:
>> 
>>> 62:  */
>>> 63: 
>>> 64: @ExtendWith(ScreenCaptureTestWatcher.class)
>> 
>> `ScreenCaptureTestWatcher` is only intended to be used with developer builds. We must not integrate a test into the repo with it enabled.
>
> I updated it and removed the `ScreenCaptureTestWatcher`

Perhaps we should keep it for a while, to capture the screenshot if it fails (there is almost zero overhead in keeping it if the tests don't fail).

We could create a followup ticket to remove it in the next test sprint.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337933257

From angorya at openjdk.org  Wed Sep 10 21:24:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Sep 2025 21:24:36 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
Message-ID: <N_t-6CkVStiaqa40lxtVfF3VzrXdVqVKb4u3SZsekSs=.52556ff9-1dba-4408-9775-717a19c612a2@github.com>

On Wed, 10 Sep 2025 14:43:11 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The test seems to be working in Linux currently, so I enabled it for Linux systems.

tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 28:

> 26: package test.robot.javafx.scene;
> 27: 
> 28: import static org.junit.jupiter.api.Assumptions.assumeTrue;

might want to change the copyright year to 2025

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337941519

From kcr at openjdk.org  Wed Sep 10 21:28:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 10 Sep 2025 21:28:31 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <pNCyqCSlcuuxVw_OM3iTQdZjaciQruOo3UQM0A9QDio=.7b29eecb-ec21-473d-8f8b-7baacd7b52e5@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <8ry8j02tBJ7bICioA1mfnV6szU1hNbz0e1G2kEhFMg0=.75b90d34-228b-46e4-870c-c2be78ef01d7@github.com>
 <ULyWvTVrFEGgesp6phD9uMwqUKcHJIcEx3Z8LtkljcA=.81454fc7-441f-475a-b042-90c2e5f3ea92@github.com>
 <pNCyqCSlcuuxVw_OM3iTQdZjaciQruOo3UQM0A9QDio=.7b29eecb-ec21-473d-8f8b-7baacd7b52e5@github.com>
Message-ID: <2AJpZSecZInIXgUH7tAwAUJuhSUoOB96Nz3y8CBxCWM=.9519809f-e0d4-46d9-99b1-61cb7c054a74@github.com>

On Wed, 10 Sep 2025 21:16:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I updated it and removed the `ScreenCaptureTestWatcher`
>
> Perhaps we should keep it for a while, to capture the screenshot if it fails (there is almost zero overhead in keeping it if the tests don't fail).
> 
> We could create a followup ticket to remove it in the next test sprint.
> 
> What do you think?

Not without qualifying it on a gradle property that is off by default. We discussed this when the new screenshot utility was first introduced.

If this is a developer convenience, then it's fine as is without being qualified. Developers can enable it as needed.

If this is ever checked into our repo, then I want a gradle property to enable it, where the default is false.

Current, we do the former. I'd be fine doing the latter and then added it as needed to intermittently failing tests. We could have our nightly headful test job set that gradle property, but I don't want it on by default when developers run "gradle ... test".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2337948093

From almatvee at openjdk.org  Wed Sep 10 22:59:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 10 Sep 2025 22:59:09 GMT
Subject: RFR: 8366217: Update GStreamer to 1.26.5
Message-ID: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>

- GStreamer updated to 1.26.5.
- Tested on all platforms with all supported formats.

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

Commit messages:
 - 8366217: Update GStreamer to 1.26.5 [v7]
 - 8366217: Update GStreamer to 1.26.5 [v6]
 - 8366217: Update GStreamer to 1.26.5 [v5]
 - 8366217: Update GStreamer to 1.26.5 [v4]
 - 8366217: Update GStreamer to 1.26.5 [v3]
 - 8366217: Update GStreamer to 1.26.5 [v2]
 - 8366217: Update GStreamer to 1.26.5

Changes: https://git.openjdk.org/jfx/pull/1894/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366217
  Stats: 18884 lines in 166 files changed: 14131 ins; 2041 del; 2712 mod
  Patch: https://git.openjdk.org/jfx/pull/1894.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1894/head:pull/1894

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

From mstrauss at openjdk.org  Wed Sep 10 23:17:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 10 Sep 2025 23:17:38 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in macOS
 26 (Tahoe)
Message-ID: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>

1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.

This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

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

Commit messages:
 - observe NSApp.effectiveAppearance
 - use NSSystemColorsDidChangeNotification

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

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

From zelmidaoui at openjdk.org  Thu Sep 11 02:04:26 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Sep 2025 02:04:26 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
Message-ID: <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>

> The test seems to be working in Linux currently, so I enabled it for Linux systems.

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Copyright update

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1893/files
  - new: https://git.openjdk.org/jfx/pull/1893/files/9c50c084..de1ee073

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

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

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

From zelmidaoui at openjdk.org  Thu Sep 11 02:04:28 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Sep 2025 02:04:28 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <N_t-6CkVStiaqa40lxtVfF3VzrXdVqVKb4u3SZsekSs=.52556ff9-1dba-4408-9775-717a19c612a2@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <N_t-6CkVStiaqa40lxtVfF3VzrXdVqVKb4u3SZsekSs=.52556ff9-1dba-4408-9775-717a19c612a2@github.com>
Message-ID: <YTfslouIqFfF8HT0ms4b0Noaeiun7RvuJqmurXfvFYg=.8235f050-8df6-4f9d-ba16-fc70c3615c10@github.com>

On Wed, 10 Sep 2025 21:21:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update
>
> tests/system/src/test/java/test/robot/javafx/scene/ContextMenuNPETest.java line 28:
> 
>> 26: package test.robot.javafx.scene;
>> 27: 
>> 28: import static org.junit.jupiter.api.Assumptions.assumeTrue;
> 
> might want to change the copyright year to 2025

Ah yes I changed it , thanks

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1893#discussion_r2338317513

From hmeda at openjdk.org  Thu Sep 11 05:37:45 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 11 Sep 2025 05:37:45 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1 [v2]
In-Reply-To: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
Message-ID: <RLpPPcrrV1aEmp6QHIkOJedm0sYNsPceeosnHbczbvA=.cdf0f0c7-6d63-4918-8eae-76429936002d@github.com>

> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1882/files
  - new: https://git.openjdk.org/jfx/pull/1882/files/309d4d5d..f1cf9815

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

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

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

From hmeda at openjdk.org  Thu Sep 11 05:53:05 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 11 Sep 2025 05:53:05 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5 [v2]
In-Reply-To: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
Message-ID: <zvZYSuX8dUGMku3of4ejLGoxDjs47LMZOiKuQPJL3k0=.5e6efaa2-b7ff-4bdb-aa59-db69f3b63966@github.com>

> Updated libxml2 to v2.14.5.
> Verified build on all platforms. No issues seen

Hima Bindu Meda 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/1886/files
  - new: https://git.openjdk.org/jfx/pull/1886/files/117cfbbd..c8d549da

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

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

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

From jdv at openjdk.org  Thu Sep 11 07:06:14 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 11 Sep 2025 07:06:14 GMT
Subject: Integrated: 8356688: [TestBug] SWT tests fail on some Linux distros
In-Reply-To: <hn1xDTYXl-Xalnh0dg1yMM9hV1_LP8lg2RVGQZxj4P8=.6d02c26d-f728-43b7-bc6c-6d11fc31137d@github.com>
References: <hn1xDTYXl-Xalnh0dg1yMM9hV1_LP8lg2RVGQZxj4P8=.6d02c26d-f728-43b7-bc6c-6d11fc31137d@github.com>
Message-ID: <5_YYZ5srp5brx57hUtOm7Yhe7lcD7kuGT8FPg0mEpn4=.fe5b2fd1-dea3-4113-ab2d-779a903d2cd7@github.com>

On Wed, 10 Sep 2025 09:56:24 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SWT unit tests were not enabled under [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) as it resulted in crash. We forced x11 as GDK backend under [JDK-8210411](https://bugs.openjdk.org/browse/JDK-8210411) but this is not sufficient in case where FXCanvas is embedded in an SWT window as captured at : https://github.com/openjdk/jfx/pull/1783#issuecomment-2844889943
> 
> Setting the environment variable in :swt:test gradle task fixes the issue. This is verified in Ubuntu 22.04 and 24.04 and swt tests run fine.

This pull request has now been integrated.

Changeset: 8fe5e284
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8fe5e28474a0558d08a8c1e2a1abd865978daf8b
Stats:     11 lines in 1 file changed: 5 ins; 5 del; 1 mod

8356688: [TestBug] SWT tests fail on some Linux distros

Reviewed-by: kcr

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

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

From jdv at openjdk.org  Thu Sep 11 09:11:40 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 11 Sep 2025 09:11:40 GMT
Subject: RFR: 8366805: Skip failing MenuDoubleShortcutTest on macOS
Message-ID: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>

Skip macOS specific MenuDoubleShortcutTest.macSceneComesBeforeMenuBar() test until the issue is fixed under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405)

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

Commit messages:
 - 8366805: Skip failing MenuDoubleShortcutTest on macOS

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

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

From kcr at openjdk.org  Thu Sep 11 12:35:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 12:35:25 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
Message-ID: <DGB_Vv9NXLiNPr3CjRLfZNedrcFzPh4fnEpME6UI3vg=.b858ea75-93af-492a-a4a4-2c476109539d@github.com>

On Thu, 11 Sep 2025 02:04:26 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The test seems to be working in Linux currently, so I enabled it for Linux systems.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1893#pullrequestreview-3211269479

From kcr at openjdk.org  Thu Sep 11 12:36:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 12:36:27 GMT
Subject: RFR: 8366805: Skip failing MenuDoubleShortcutTest on macOS
In-Reply-To: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
References: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
Message-ID: <l9WlvlG3wMVUGV6gXvIauj4tuXPCZl7pdNSlqB_B9zg=.4c0b0e5a-f4d0-48cb-94da-d5fd0044e4da@github.com>

On Thu, 11 Sep 2025 09:05:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Skip macOS specific MenuDoubleShortcutTest.macSceneComesBeforeMenuBar() test until the issue is fixed under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1896#pullrequestreview-3211275321

From kcr at openjdk.org  Thu Sep 11 12:39:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 12:39:44 GMT
Subject: RFR: 8366217: Update GStreamer to 1.26.5
In-Reply-To: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
References: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
Message-ID: <hB5-oKCYP-L7aEfHzASfPRR9YBrhQdSxolLOi6c2XwM=.ddf40127-1ccd-4170-947a-34e13fb9a04e@github.com>

On Wed, 10 Sep 2025 19:33:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GStreamer updated to 1.26.5.
> - Tested on all platforms with all supported formats.

Reviewers: @arapte @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1894#issuecomment-3280415316

From kcr at openjdk.org  Thu Sep 11 13:02:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 13:02:40 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1 [v2]
In-Reply-To: <RLpPPcrrV1aEmp6QHIkOJedm0sYNsPceeosnHbczbvA=.cdf0f0c7-6d63-4918-8eae-76429936002d@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
 <RLpPPcrrV1aEmp6QHIkOJedm0sYNsPceeosnHbczbvA=.cdf0f0c7-6d63-4918-8eae-76429936002d@github.com>
Message-ID: <kjteCBSF4HoDhPH_OehOaJ5EMuHoRfMTfQh9qrtj73M=.bc5dc7cd-cf88-4b2c-a1d7-b9d54521624c@github.com>

On Thu, 11 Sep 2025 05:37:45 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1882#pullrequestreview-3211425200

From kcr at openjdk.org  Thu Sep 11 13:34:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 13:34:37 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5 [v2]
In-Reply-To: <zvZYSuX8dUGMku3of4ejLGoxDjs47LMZOiKuQPJL3k0=.5e6efaa2-b7ff-4bdb-aa59-db69f3b63966@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
 <zvZYSuX8dUGMku3of4ejLGoxDjs47LMZOiKuQPJL3k0=.5e6efaa2-b7ff-4bdb-aa59-db69f3b63966@github.com>
Message-ID: <txhg8f3kXsFIi3AOgGkfVxI-cByK7NwshQjpUFXvW-0=.8f63d0c6-5f8b-40dc-b2e8-a8eaf628dfea@github.com>

On Thu, 11 Sep 2025 05:53:05 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxml2 to v2.14.5.
>> Verified build on all platforms. No issues seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused files

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1886#pullrequestreview-3211607237

From kcr at openjdk.org  Thu Sep 11 13:38:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 11 Sep 2025 13:38:39 GMT
Subject: RFR: 8366805: Skip failing MenuDoubleShortcutTest on macOS
In-Reply-To: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
References: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
Message-ID: <fvZqlTxqj3IE_V84Pgpg-Y4R6TCAIUr1SEwqQjogikU=.f79482f8-142a-47e4-bc63-f66edc8e8a1c@github.com>

On Thu, 11 Sep 2025 09:05:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Skip macOS specific MenuDoubleShortcutTest.macSceneComesBeforeMenuBar() test until the issue is fixed under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405)

Since this is a simple problem listing of a test, no need to wait 24 hours to integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1896#issuecomment-3280738299

From jdv at openjdk.org  Thu Sep 11 14:22:55 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 11 Sep 2025 14:22:55 GMT
Subject: Integrated: 8366805: Skip failing MenuDoubleShortcutTest on macOS
In-Reply-To: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
References: <fmFxRxrToyYk1kTGcM3K-RudnrVjhJG72HuoH5RrbNU=.89aea4c0-ea48-44ac-aa93-134bb2ec4835@github.com>
Message-ID: <ionp45DEBjtiPS6LzwgZo0bOz19sGTnNRz2VhbO52p4=.1c233a52-1d14-49f5-9436-aff2b755aec6@github.com>

On Thu, 11 Sep 2025 09:05:20 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Skip macOS specific MenuDoubleShortcutTest.macSceneComesBeforeMenuBar() test until the issue is fixed under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405)

This pull request has now been integrated.

Changeset: 89406ad4
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/89406ad45e4bfe4a235c21671a6f4ab2eec081ff
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8366805: Skip failing MenuDoubleShortcutTest on macOS

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Thu Sep 11 14:34:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Sep 2025 14:34:15 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
Message-ID: <F9V4Kt1CwuWLp1cEKDNN8d5R09Vz7t0lYwd_ZpFGDI8=.db564086-49df-4651-9eb8-bbbb1a8647a0@github.com>

On Thu, 11 Sep 2025 02:04:26 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The test seems to be working in Linux currently, so I enabled it for Linux systems.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1893#pullrequestreview-3211993397

From zelmidaoui at openjdk.org  Thu Sep 11 15:36:54 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Sep 2025 15:36:54 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
Message-ID: <ppI83SXbWCn1OTovRQ_7pRS9DGpEhpAiaCIsXoEBAHg=.607d56a3-da21-422e-ae7d-e71f55db2222@github.com>

On Thu, 11 Sep 2025 02:04:26 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The test seems to be working in Linux currently, so I enabled it for Linux systems.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Thank you for reviewing

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

PR Comment: https://git.openjdk.org/jfx/pull/1893#issuecomment-3281451895

From duke at openjdk.org  Thu Sep 11 15:36:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 15:36:55 GMT
Subject: RFR: 8321625: ContextMenuNPETest fails intermittently on Linux
 [v2]
In-Reply-To: <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
 <azobabANFLhRZC1FYcbQcTuFTDadwvXZcntAN4mKZrc=.cddbf967-6494-4d17-918a-71cfb3e6d647@github.com>
Message-ID: <D5KZkJtk2P24AhYtG6WBcm1CrrI5qjc8dPjoEI9nz2I=.db692570-2f23-4c99-99d9-4b18c5331701@github.com>

On Thu, 11 Sep 2025 02:04:26 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The test seems to be working in Linux currently, so I enabled it for Linux systems.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

@Ziad-Mid 
Your change (at version de1ee073e18140abff9ea66afbf83844957a2aa9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1893#issuecomment-3281463990

From zelmidaoui at openjdk.org  Thu Sep 11 15:40:08 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 11 Sep 2025 15:40:08 GMT
Subject: Integrated: 8321625: ContextMenuNPETest fails intermittently on Linux
In-Reply-To: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
References: <vy4bZqCxv_W-ui9epNbYyXhrKb-GxczJQlTjoIOGS-Y=.df7824b8-2e19-46ca-bd7c-007f289aecf8@github.com>
Message-ID: <_t46BnYztigvtjwC0kM41AFGb0_YkkPtvFLKGlpyq64=.349cbec3-b0f7-40ab-afd8-d9e77ce9d842@github.com>

On Wed, 10 Sep 2025 14:43:11 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The test seems to be working in Linux currently, so I enabled it for Linux systems.

This pull request has now been integrated.

Changeset: 569682ca
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/569682ca4688614e949f6b914355976035de6e32
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8321625: ContextMenuNPETest fails intermittently on Linux

Reviewed-by: kcr, angorya

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

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

From jdv at openjdk.org  Fri Sep 12 08:40:44 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 12 Sep 2025 08:40:44 GMT
Subject: RFR: 8340378: [XWayland] FXCanvas apps and tests crash on Ubuntu 24.04
Message-ID: <yN7s2jKfKLBBhSLa1eJQ1wsdn9tH2XcMk1jVKLYEYOw=.1d4498df-b674-4843-9f09-f7845a505851@github.com>

As mentioned in recent PR : https://github.com/openjdk/jfx/pull/1890#issue-3401783091, we need to set environment variable GDK_BACKEND=x11 for running HelloFXCanvas also.

There is no correct way of setting environment variable through Java code/Netbeans project files. So we are capturing this additional step for Linux in README.txt.

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

Commit messages:
 - 8340378: [XWayland] FXCanvas apps and tests crash on Ubuntu 24.04

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

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

From kcr at openjdk.org  Fri Sep 12 14:33:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 12 Sep 2025 14:33:45 GMT
Subject: RFR: 8340378: [XWayland] FXCanvas apps and tests crash on Ubuntu
 24.04
In-Reply-To: <yN7s2jKfKLBBhSLa1eJQ1wsdn9tH2XcMk1jVKLYEYOw=.1d4498df-b674-4843-9f09-f7845a505851@github.com>
References: <yN7s2jKfKLBBhSLa1eJQ1wsdn9tH2XcMk1jVKLYEYOw=.1d4498df-b674-4843-9f09-f7845a505851@github.com>
Message-ID: <GDMfhgyXah2dfQYsODB8tQmeuC6N5UvvxbiHxeM-4i0=.b86a3f3d-bb06-4eb1-bc60-f27d95ccc842@github.com>

On Fri, 12 Sep 2025 08:32:38 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> As mentioned in recent PR : https://github.com/openjdk/jfx/pull/1890#issue-3401783091, we need to set environment variable GDK_BACKEND=x11 for running HelloFXCanvas also.
> 
> There is no correct way of setting environment variable through Java code/Netbeans project files. So we are capturing this additional step for Linux in README.txt.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1898#pullrequestreview-3216991118

From angorya at openjdk.org  Fri Sep 12 16:06:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Sep 2025 16:06:47 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
Message-ID: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>

This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.

In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).

## How To

To redirect stderr and later check the exceptions, surround your code with

`ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.

To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.

To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.

## Miscellaneous

For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.

## Questions

- should we fail the current test with `Assertions.fail()` in case of a mismatch?

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

Commit messages:
 - whitespace
 - revert intentionally failing test
 - 2025
 - fixed utility class name
 - suppress stderr

Changes: https://git.openjdk.org/jfx/pull/1897/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336332
  Stats: 1035 lines in 16 files changed: 348 ins; 86 del; 601 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From kcr at openjdk.org  Fri Sep 12 17:54:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 12 Sep 2025 17:54:35 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <-yX7oMuP-CB0N6eXpa1aMLGjZUjsi7dPgOtyFW2v0ew=.84251977-ff94-4d04-b7bd-d25c21cbf844@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

I see that you focused on javafx.base, which is where many of the problems are. Do you plan to update this PR for the other modules and for system tests (the latter also has several exceptions and lots of noise), or will you file a follow-up issue to take up after this one is done?

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286325178

From angorya at openjdk.org  Fri Sep 12 18:02:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Sep 2025 18:02:28 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <P-bdCpUGjG9xEwHVhj4XsQlFzqufhsLH5w2opQKf7c8=.4d255592-361f-4af2-a6bd-dd21381b8b74@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

good point.
no, this PR is only for the headful tests as they cause the most grief when analyzing the failures.

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286342988

From mstrauss at openjdk.org  Fri Sep 12 18:18:26 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 12 Sep 2025 18:18:26 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <Y1JuKdmfw_H22_N81rww10R9QSj-g9puwlZG3YLqrnM=.d8043f6b-6ad9-448b-b6ea-8c32c30ed275@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

The `ErrorLoggingUtility` class manages static state, and requires users to follow a protocol to avoid messing up its internal state. Have you considered using a try-with-resources scope to make the API easier to use, for example:


try (var util = ErrorLoggingUtility.suppressStdErr()) {
    // test something
    // ...
    //

    util.checkWarning(NullPointerException.class);
} // internal state is restored at the end of the block

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286382236

From angorya at openjdk.org  Fri Sep 12 18:26:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Sep 2025 18:26:29 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <tXo8Re6JjXea5NIEcWVtgVeA6SX2Cn7S1viJzqhXjmM=.347f435a-7f17-43a1-9a8e-645d59156086@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

Good point.  It already has a static state (error log record), and on top of that try with resources will not work in the bulk use case of `@BeforeEach` and `@AfterEach`

Plus, it's a test utility.

I did try to explain the usage in javadoc - maybe that can be further clarified?

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286402718

From arapte at openjdk.org  Fri Sep 12 18:36:55 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 12 Sep 2025 18:36:55 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS
Message-ID: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>

Issue: 
On MacOS, several tests fail intermittently.

Fix: 
- The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
- If the Ctrl + Click is avoided, then the test failures are not observed.
- So this change comments out the part of the test in question.
- A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)

Verification:
1. Verified the headful test with full run, 12 times. The issue does not occur.
Without this change, the tests do fail more often.
2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
With this change, no test failure is observed. Several times, tested 120 iterations.

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

Commit messages:
 - skip Ctrl + click

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

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

From angorya at openjdk.org  Fri Sep 12 18:44:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Sep 2025 18:44:13 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS
In-Reply-To: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
Message-ID: <VlGVbkUna6EA6HG74tnVd4oeO44hCU618E0NvQwGEWw=.c019c7a1-10ee-4a0a-891e-af54b974c157@github.com>

On Fri, 12 Sep 2025 18:31:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> On MacOS, several tests fail intermittently.
> 
> Fix: 
> - The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
> - If the Ctrl + Click is avoided, then the test failures are not observed.
> - So this change comments out the part of the test in question.
> - A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)
> 
> Verification:
> 1. Verified the headful test with full run, 12 times. The issue does not occur.
> Without this change, the tests do fail more often.
> 2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
> With this change, no test failure is observed. Several times, tested 120 iterations.

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1899#pullrequestreview-3218334050

From kcr at openjdk.org  Fri Sep 12 18:49:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 12 Sep 2025 18:49:49 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS
In-Reply-To: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
Message-ID: <j9etS018yf1gnwNr2CUILt5PuR2_xb8B0ZbKqS8GGr0=.16f1953d-d975-45a3-af4f-fffb7def57ad@github.com>

On Fri, 12 Sep 2025 18:31:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> On MacOS, several tests fail intermittently.
> 
> Fix: 
> - The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
> - If the Ctrl + Click is avoided, then the test failures are not observed.
> - So this change comments out the part of the test in question.
> - A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)
> 
> Verification:
> 1. Verified the headful test with full run, 12 times. The issue does not occur.
> Without this change, the tests do fail more often.
> 2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
> With this change, no test failure is observed. Several times, tested 120 iterations.

LGTM with one minor suggestion for the comment. I'll reapprove if you change it.

tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewContextMenuSortTest.java line 108:

> 106: 
> 107:         /*
> 108:         // This part of test is causing intermittent test failures on MacOS. see: JDK-8359154

Suggestion:

        // Skipped due to JDK-8367566
        // This part of test is causing intermittent test failures on MacOS. see: JDK-8359154


I would add a clear comment at the beginning with the bug ID that is the reason for skipping the test (the new bug you filed, JDK-8367566).

Also, we normally wouldn't list the bug ID of the bug you are fixing (JDK-8359154), but it's OK in this case, since the comment is explaining why we are skipping the test; the whole comment block can be removed when JDK-8367566 is fixed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1899#pullrequestreview-3218355349
PR Review Comment: https://git.openjdk.org/jfx/pull/1899#discussion_r2345142117

From mstrauss at openjdk.org  Fri Sep 12 18:50:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 12 Sep 2025 18:50:24 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <tXo8Re6JjXea5NIEcWVtgVeA6SX2Cn7S1viJzqhXjmM=.347f435a-7f17-43a1-9a8e-645d59156086@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <tXo8Re6JjXea5NIEcWVtgVeA6SX2Cn7S1viJzqhXjmM=.347f435a-7f17-43a1-9a8e-645d59156086@github.com>
Message-ID: <pHo0SMMYy_71cOX8m0DHagBsoHes2omc4tUCOW8mhiI=.6eced256-d457-4a57-97d9-5477dd9697dc@github.com>

On Fri, 12 Sep 2025 18:24:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good point. It already has a static state (error log record), and on top of that try with resources will not work in the bulk use case of `@BeforeEach` and `@AfterEach`

Why wouldn't it work? If you _really_ need to, you can store the `AutoClosable` in `@BeforeEach` and then call the close method in `@AfterEach`. But I would also prefer to not scatter around code in before-each and after-each methods, but to have each test be as stand-alone as possible, especially when it comes to scoping.

Whether `ErrorLoggingUtility` has static state is also immaterial (that would only be important if tests were to be run in parallel), what matters is the API. Using an auto-closable scope has the following advantages:
1. Using the tool is easy, as you can only call methods that are applicable for the state of the test. If you want to check the log output, you need to have an active scope instance.
2. It can't be misused, as you can't call methods in the wrong order.
3. The static state will always be well-defined.

Yes, it's only a test utility, but the API is really suboptimal no matter how I look at it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286467188

From arapte at openjdk.org  Fri Sep 12 19:14:54 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 12 Sep 2025 19:14:54 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS [v2]
In-Reply-To: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
Message-ID: <2A_05m8rBIsHi0R8P9oiyXCZKANkR3JKdwazWG5WVA8=.bb4a0111-a69f-4b99-ae05-53dbc86104b4@github.com>

> Issue: 
> On MacOS, several tests fail intermittently.
> 
> Fix: 
> - The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
> - If the Ctrl + Click is avoided, then the test failures are not observed.
> - So this change comments out the part of the test in question.
> - A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)
> 
> Verification:
> 1. Verified the headful test with full run, 12 times. The issue does not occur.
> Without this change, the tests do fail more often.
> 2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
> With this change, no test failure is observed. Several times, tested 120 iterations.

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

  update comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1899/files
  - new: https://git.openjdk.org/jfx/pull/1899/files/052cb57e..18f73a90

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

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

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

From arapte at openjdk.org  Fri Sep 12 19:14:55 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 12 Sep 2025 19:14:55 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS [v2]
In-Reply-To: <j9etS018yf1gnwNr2CUILt5PuR2_xb8B0ZbKqS8GGr0=.16f1953d-d975-45a3-af4f-fffb7def57ad@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
 <j9etS018yf1gnwNr2CUILt5PuR2_xb8B0ZbKqS8GGr0=.16f1953d-d975-45a3-af4f-fffb7def57ad@github.com>
Message-ID: <9ubutdAkfh7mlfBZ2HhqqJovsMsUAYI5NREi-QnCN70=.43b70162-e025-4332-8758-e0135df281a4@github.com>

On Fri, 12 Sep 2025 18:44:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comment
>
> tests/system/src/test/java/test/robot/javafx/scene/tableview/TableViewContextMenuSortTest.java line 108:
> 
>> 106: 
>> 107:         /*
>> 108:         // This part of test is causing intermittent test failures on MacOS. see: JDK-8359154
> 
> Suggestion:
> 
>         // Skipped due to JDK-8367566
>         // This part of test is causing intermittent test failures on MacOS. see: JDK-8359154
> 
> 
> I would add a clear comment at the beginning with the bug ID that is the reason for skipping the test (the new bug you filed, JDK-8367566).
> 
> Also, we normally wouldn't list the bug ID of the bug you are fixing (JDK-8359154), but it's OK in this case, since the comment is explaining why we are skipping the test; the whole comment block can be removed when JDK-8367566 is fixed.

Thank you for the review. 
Updated the comment as guided, please check.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1899#discussion_r2345201110

From kcr at openjdk.org  Fri Sep 12 19:18:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 12 Sep 2025 19:18:30 GMT
Subject: RFR: 8359154: Intermittent system test failures on macOS [v2]
In-Reply-To: <2A_05m8rBIsHi0R8P9oiyXCZKANkR3JKdwazWG5WVA8=.bb4a0111-a69f-4b99-ae05-53dbc86104b4@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
 <2A_05m8rBIsHi0R8P9oiyXCZKANkR3JKdwazWG5WVA8=.bb4a0111-a69f-4b99-ae05-53dbc86104b4@github.com>
Message-ID: <yizvOikJxdOn7TlKh1-pJlFgEwBQaR4VxuZ8lOgJpq8=.a9a90033-8c5e-42e8-9d65-64b32f01a484@github.com>

On Fri, 12 Sep 2025 19:14:54 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Issue: 
>> On MacOS, several tests fail intermittently.
>> 
>> Fix: 
>> - The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
>> - If the Ctrl + Click is avoided, then the test failures are not observed.
>> - So this change comments out the part of the test in question.
>> - A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)
>> 
>> Verification:
>> 1. Verified the headful test with full run, 12 times. The issue does not occur.
>> Without this change, the tests do fail more often.
>> 2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
>> With this change, no test failure is observed. Several times, tested 120 iterations.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment

Marked as reviewed by kcr (Lead).

Since this is just skipping a failing test, OK to integrate without waiting 24 hours.

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

PR Review: https://git.openjdk.org/jfx/pull/1899#pullrequestreview-3218496737
PR Comment: https://git.openjdk.org/jfx/pull/1899#issuecomment-3286546843

From arapte at openjdk.org  Fri Sep 12 19:22:28 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 12 Sep 2025 19:22:28 GMT
Subject: Integrated: 8359154: Intermittent system test failures on macOS
In-Reply-To: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
References: <m4b9JOmYBFtNA1DgdMbHJEyfrt2GG0HmArVe4ly76gs=.39c1c7af-6dc4-49c1-8f16-fe3e5a9ebd08@github.com>
Message-ID: <7nVVQKhls5vlpavWltr8PUtEXdFwaBrxjDygWhQ7x9Y=.4c4ffc9c-a195-44ea-ab5b-12cdbddd16ec@github.com>

On Fri, 12 Sep 2025 18:31:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> On MacOS, several tests fail intermittently.
> 
> Fix: 
> - The test TableViewContextMenuSortTest.testContextMenuRequestDoesNotSort() performs a Ctrl + Click test only on MacOS platform.
> - If the Ctrl + Click is avoided, then the test failures are not observed.
> - So this change comments out the part of the test in question.
> - A follow-up ticket is created to investigate/update the test [JDK-8367566](https://bugs.openjdk.org/browse/JDK-8367566)
> 
> Verification:
> 1. Verified the headful test with full run, 12 times. The issue does not occur.
> Without this change, the tests do fail more often.
> 2. @beldenfox shared a way to reproduce the failures, in a comment in JBS ticket : [JDK-8359154](https://bugs.openjdk.org/browse/JDK-8359154)**:** If these 5 tests are run repeatedly TableViewClickOnTroughTest, TableViewContextMenuSortTest, TableViewResizeColumnToFitContentTest, TreeTableViewChangeRootTest, and TreeTableViewResizeColumnToFitContentTest, then the issue could occur in 'n' iterations < 120. 
> With this change, no test failure is observed. Several times, tested 120 iterations.

This pull request has now been integrated.

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

8359154: Intermittent system test failures on macOS

Reviewed-by: kcr, angorya

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

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

From mfox at openjdk.org  Fri Sep 12 19:36:09 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 12 Sep 2025 19:36:09 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <ij-l2TAfi3uQdRUR6T5t-wWMMg3fFcecTRSKNfyGgTg=.d5b3d9ba-56e4-4fe6-aea7-9d95eaee5c44@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

I was able to test this on macOS 13, 15, and 26 RC. I only focused on changes to the dark/light appearance, accent color, and highlight color. All versions of the OS behaved identically and updated the platform preferences reliably.

Under the hood I can see that `updatePreferences` can be called up to three times when the accent color changes. In most cases this leads to just a single set of changes being broadcast on the Java side. The exception is when I change the accent color to or from "graphite". When changing from "multicolor" to "graphite" I see three sets of changes each touching a different set of preferences with the exception of macOS.NSColor.keyboardFocusIndicatorColor which is changed twice, once in the second set of changes and again in the third. When changing from "graphite" to "multicolor" I see two sets of changes and macOS.NSColor.keyboardFocusIndicatorColor is altered in both of them.

I don't consider these bugs but this is a change from the old behavior. "Graphite" is a special accent color which also affects things like the stoplight controls in the title bar which go grayscale.

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

PR Comment: https://git.openjdk.org/jfx/pull/1895#issuecomment-3286585962

From angorya at openjdk.org  Fri Sep 12 20:05:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Sep 2025 20:05:43 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <eYhza2BaiRRijlLQyyFapw9HkvnYzhGn-N6uD--c0ss=.3663e129-2abe-4600-b645-d0e67b5856f1@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

These are all valid points, but keep in mind that `System.setErr()` is static to begin with.  All the system and headful tests are single threaded by design, and this is rather unlikely to change.

Whether to use BeforeEach/AfterEach or standalone test is up to the test developers (this PR contains both cases actually).  I would say re-designing the existing tests to be standalone (`SelectBindingTest` for example) is out of scope for this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3286674215

From mstrauss at openjdk.org  Sat Sep 13 00:48:39 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 13 Sep 2025 00:48:39 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <E9zOkm3Uui7ASAVynPWrj5YXj7CZG6dVbKoMmmNVbbI=.0ac69aa1-56c0-4d91-becf-a1e32345d3f9@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

That's probably because the one-second delay to pick up the accent color is no longer necessary with the correct notification APIs. In general, we don't specify how preference change notifications are delivered. I've previously proposed [change aggregation](https://github.com/openjdk/jfx/pull/1810) on the Java side, because multiple notifications are also a thing on Windows.

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

PR Comment: https://git.openjdk.org/jfx/pull/1895#issuecomment-3287280055

From duke at openjdk.org  Sat Sep 13 13:33:51 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Sat, 13 Sep 2025 13:33:51 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <VvjXnaH3Ph60VU7SgFS3TJ9LKiIBSEEnSfg4HnwlF0c=.ef0051e9-bbb7-4309-a746-d5421fd0e050@github.com>
References: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
 <VvjXnaH3Ph60VU7SgFS3TJ9LKiIBSEEnSfg4HnwlF0c=.ef0051e9-bbb7-4309-a746-d5421fd0e050@github.com>
Message-ID: <yCXNwRC5nMmOGkHA9MxY4HBXoBwcbU8PQuNcYV-rdig=.794a6a29-bfe1-4037-a572-9be3c28d0c6a@github.com>

On Thu, 3 Jul 2025 07:04:24 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX.
>> 
>> The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method.
>> 
>> The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus.
>> 
>> I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it worked without any errors, but on further testing I noticed some issues with the menu bar. I am currently writing the test and fixes for it.
>> 
>> Co-Author: @FlorianKirmaier
>
> The model we are trying to have here is quite simple.
> 
> **Background**
> When a Window/Toolkit gets focused, it defines which menus should be shown.
> This is done by removing the old menus, and adding their own.
> This is basically, what the OS does, when you switch from Application A to B, just inside one process.
> 
> Actually, we only wanted to make the JavaFX menu work when Swing/AWT was started first.
> But as far as we see, our solution also makes all combinations work.
> 
> **Test**
> What is definitely missing, which we will add, are unit tests.
> We have already investigated - there is an Apple Command line API, which allows us to read out which menus are currently shown. We will add some unit-tests, which should provide confidence that this is working reliably.
> 
> I hope these tests will improve the confidence, that this solution is correct and maintainable.

I decided to close this PR and to open a new one after discussing it with @FlorianKirmaier as we both think this will simplify things. This PR contains a lot of comments on the first version of the fix and since it was entirely rewritten makes it unnecessarily complex.

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

PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-3288363299

From jhendrikx at openjdk.org  Sat Sep 13 18:00:21 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 13 Sep 2025 18:00:21 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates wrong
 initial size
Message-ID: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>

Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10

In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.

The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.

In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).

With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).

The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.

(As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).

As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

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

Commit messages:
 - Calculate dependent size for biased Tabs before calculating other size

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

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

From jbhaskar at openjdk.org  Sun Sep 14 02:19:21 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sun, 14 Sep 2025 02:19:21 GMT
Subject: RFR: 8367374: JavaFX debug builds fail on Windows
Message-ID: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>

Issue:  data_as_asm tool fails to generate cpp object from ICU symbols file when webkit builds in debug mode.
Solution: The ICU third party lib already using MSVC to build , Make ICU build in Release mode.

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

Commit messages:
 - 8367374: JavaFX debug builds fail on Windows

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

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

From jbhaskar at openjdk.org  Sun Sep 14 02:31:06 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sun, 14 Sep 2025 02:31:06 GMT
Subject: RFR: 8329874: JavaFX debug builds fail on Linux
Message-ID: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>

Issue: JavaFX debug builds fail on Linux
The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.

Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

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

Commit messages:
 - 8329874: JavaFX debug builds fail on Linux

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

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

From jdv at openjdk.org  Mon Sep 15 03:30:49 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 15 Sep 2025 03:30:49 GMT
Subject: Integrated: 8340378: [XWayland] FXCanvas apps and tests crash on
 Ubuntu 24.04
In-Reply-To: <yN7s2jKfKLBBhSLa1eJQ1wsdn9tH2XcMk1jVKLYEYOw=.1d4498df-b674-4843-9f09-f7845a505851@github.com>
References: <yN7s2jKfKLBBhSLa1eJQ1wsdn9tH2XcMk1jVKLYEYOw=.1d4498df-b674-4843-9f09-f7845a505851@github.com>
Message-ID: <f5C7z6ceX6KNjFSYmR1vEYbKh5Rl5jRILuT1fRh2s9c=.ea847831-f1cf-49c1-be34-5f73a5132d34@github.com>

On Fri, 12 Sep 2025 08:32:38 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> As mentioned in recent PR : https://github.com/openjdk/jfx/pull/1890#issue-3401783091, we need to set environment variable GDK_BACKEND=x11 for running HelloFXCanvas also.
> 
> There is no correct way of setting environment variable through Java code/Netbeans project files. So we are capturing this additional step for Linux in README.txt.

This pull request has now been integrated.

Changeset: 17e37c21
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/17e37c21d7afdf435138e2068ea03c7ecc1bbba1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8340378: [XWayland] FXCanvas apps and tests crash on Ubuntu 24.04

Reviewed-by: kcr

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

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

From hmeda at openjdk.org  Mon Sep 15 05:33:05 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 15 Sep 2025 05:33:05 GMT
Subject: RFR: 8366744 : Update SQLite to 3.50.4
Message-ID: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>

Updated SQLite to v 3.50.4. verified build on all platforms. No issue seen

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

Commit messages:
 - update version info
 - whitespace correction
 - update sqlite to 3.50.4

Changes: https://git.openjdk.org/jfx/pull/1903/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1903&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366744
  Stats: 3843 lines in 4 files changed: 2063 ins; 554 del; 1226 mod
  Patch: https://git.openjdk.org/jfx/pull/1903.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1903/head:pull/1903

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

From sykora at openjdk.org  Mon Sep 15 08:00:28 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 15 Sep 2025 08:00:28 GMT
Subject: RFR: 8361893 : Update libxml2 to 2.14.5 [v2]
In-Reply-To: <zvZYSuX8dUGMku3of4ejLGoxDjs47LMZOiKuQPJL3k0=.5e6efaa2-b7ff-4bdb-aa59-db69f3b63966@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
 <zvZYSuX8dUGMku3of4ejLGoxDjs47LMZOiKuQPJL3k0=.5e6efaa2-b7ff-4bdb-aa59-db69f3b63966@github.com>
Message-ID: <3pMq072TXI4n-sT2UnkmIGiwA3HCTmAphWfNsd6EQX0=.7b1ad310-0d79-4ba7-94f8-00b5ecdc0d80@github.com>

On Thu, 11 Sep 2025 05:53:05 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxml2 to v2.14.5.
>> Verified build on all platforms. No issues seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused files

Builds and tests ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1886#pullrequestreview-3223338109

From sykora at openjdk.org  Mon Sep 15 10:10:36 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 15 Sep 2025 10:10:36 GMT
Subject: RFR: 8361644 : Update ICU4C to 77.1 [v2]
In-Reply-To: <RLpPPcrrV1aEmp6QHIkOJedm0sYNsPceeosnHbczbvA=.cdf0f0c7-6d63-4918-8eae-76429936002d@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
 <RLpPPcrrV1aEmp6QHIkOJedm0sYNsPceeosnHbczbvA=.cdf0f0c7-6d63-4918-8eae-76429936002d@github.com>
Message-ID: <GDfLbW4LWpHqhVJTQf4Tx8G8qLXlplJXgogf30vdsWY=.024b4474-546c-4586-9ba9-320c6ce50ee5@github.com>

On Thu, 11 Sep 2025 05:37:45 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Builds and tests ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1882#pullrequestreview-3223853782

From sykora at openjdk.org  Mon Sep 15 11:56:41 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 15 Sep 2025 11:56:41 GMT
Subject: RFR: 8366217: Update GStreamer to 1.26.5
In-Reply-To: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
References: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
Message-ID: <2WJybce1hTPKU-iE2XwnmQsOxvzjBZDfXF8E-P2RhyQ=.4bbd8605-96be-4d74-bfb8-8b857bc3a89e@github.com>

On Wed, 10 Sep 2025 19:33:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GStreamer updated to 1.26.5.
> - Tested on all platforms with all supported formats.

Builds and tests all went fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1894#pullrequestreview-3224247548

From kcr at openjdk.org  Mon Sep 15 12:11:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 12:11:40 GMT
Subject: RFR: 8367374: JavaFX debug builds fail on Windows
In-Reply-To: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
References: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
Message-ID: <XzDR3j9StIRUqKzd02AtpkDk9e9mB3QCsHMjDVbdqoc=.3ab5472c-56bf-4cbe-acf3-6293d2136223@github.com>

On Sun, 14 Sep 2025 02:12:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue:  data_as_asm tool fails to generate cpp object from ICU symbols file when webkit builds in debug mode.
> Solution: The ICU third party lib already using MSVC to build , Make ICU build in Release mode.

Reviewers: @kevinrushforth @HimaBinduMeda

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

PR Comment: https://git.openjdk.org/jfx/pull/1901#issuecomment-3291844806

From kcr at openjdk.org  Mon Sep 15 12:13:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 12:13:23 GMT
Subject: RFR: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
References: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
Message-ID: <r8Zc7iEK6r2qlpNwsQ68RujZVJQZDg5iS00FyEHE5uk=.cc60ee47-710c-4509-a211-cb76a850df11@github.com>

On Sun, 14 Sep 2025 02:24:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: JavaFX debug builds fail on Linux
> The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.
> 
> Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

Reviewers: @kevinrushforth @HimaBinduMeda

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

PR Comment: https://git.openjdk.org/jfx/pull/1902#issuecomment-3291847885

From kcr at openjdk.org  Mon Sep 15 12:14:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 12:14:02 GMT
Subject: RFR: 8366744 : Update SQLite to 3.50.4
In-Reply-To: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
References: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
Message-ID: <2XvtPwGQfOiUSqWHdRDeue6PTlhOlj_xsmOept5YIxg=.f0beb453-9d13-4732-9283-841da5305aa6@github.com>

On Mon, 15 Sep 2025 05:28:52 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated SQLite to v 3.50.4. verified build on all platforms. No issue seen

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1903#issuecomment-3291850878

From kcr at openjdk.org  Mon Sep 15 15:10:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 15:10:57 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v2]
In-Reply-To: <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
 <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
Message-ID: <CNooORvpFVWAvN1YEsgODvgA7mqrVZB6BV6Q0QbcRts=.a74c0213-526a-4723-a865-119f8f4af197@github.com>

On Tue, 9 Sep 2025 20:26:15 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabled system test on Linux, DECORATED stage is changing height

Reviewers: @lukostyra @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1889#issuecomment-3292683555

From kcr at openjdk.org  Mon Sep 15 15:13:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 15:13:11 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6
In-Reply-To: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
Message-ID: <htGa7qwXtO3Mm6CPYc95UJnngjCdCGagcNftHT_JqGw=.1a5b0e7b-d281-42d9-ad98-55d185ddabaf@github.com>

On Mon, 8 Sep 2025 19:49:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - readme.md: 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`
> - TableView page: canvas based cell and row factories
> - Dialog page
> - Progress Bar Page
> - additional scripts in the WritingSystemsDemo
> - pure Swing JTextField/JTextArea window
> - ImageView page
> - AudioClip page
> - events in Drag and Drop page
> - added miscellaneous options
> - TextFlow page: updated hit info visualization, tab stop policy
> - WebView page: added direct html input
> 
> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

@arapte Can you review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3292689436

From kcr at openjdk.org  Mon Sep 15 15:15:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 15 Sep 2025 15:15:15 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <hVT-lXZwt-PR3xSnR0YRLRYhFISBjhENmE-ZpDLrSTc=.ccfd770d-3cde-4d71-aa9d-0e191fb64953@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

Reviewers: @arapte @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3292700722

From duke at openjdk.org  Mon Sep 15 16:26:05 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Mon, 15 Sep 2025 16:26:05 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: <0gNgRbGpbITe31QNWxaYjv3FjQPQEbsgeKe1ZaEJt5I=.be2394a9-e45a-4671-a231-c5f79e6f4aa4@github.com>
References: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
 <0gNgRbGpbITe31QNWxaYjv3FjQPQEbsgeKe1ZaEJt5I=.be2394a9-e45a-4671-a231-c5f79e6f4aa4@github.com>
Message-ID: <s9xOslFfAmilX6FEEqA5WnkaHPBBnECXnxTdX8N_Itk=.9196add9-c5b0-43f3-be16-7dfd10b162de@github.com>

On Sun, 31 Aug 2025 07:36:28 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX.
>> 
>> The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method.
>> 
>> The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus.
>> 
>> I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it worked without any errors, but on further testing I noticed some issues with the menu bar. I am currently writing the test and fixes for it.
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

I have now created the new PR: https://github.com/openjdk/jfx/pull/1904

I also have taken into account the very good advice to let the AWT devs take a look at the PR and stated what the fix does , how it works and why we need this fix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-3292978242

From duke at openjdk.org  Mon Sep 15 16:29:00 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Mon, 15 Sep 2025 16:29:00 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
Message-ID: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>

This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.

# Behavior before

If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 

One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.


# Behavior after

The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.


# Tests

This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.


# Additional benifits 

This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.


# Review from AWT

In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.


# Add disable flag?

We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.


Co-Author: @FlorianKirmaier

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

Commit messages:
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

Changes: https://git.openjdk.org/jfx/pull/1904/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359108
  Stats: 838 lines in 11 files changed: 823 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1904.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1904/head:pull/1904

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

From hmeda at openjdk.org  Mon Sep 15 18:10:08 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 15 Sep 2025 18:10:08 GMT
Subject: Integrated: 8361893 : Update libxml2 to 2.14.5
In-Reply-To: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
References: <-ctFMXdTTANkHfAQHVqawofo8SU2At86IJustF3Us5M=.a0afe954-0492-42aa-b1df-5ddbe2fd5395@github.com>
Message-ID: <DHPtglY_J7jvzgYJHtp2qhcIqzeGhogzQKuGc7DW7Yk=.1c387e43-a57e-4768-9bb7-42a17a743696@github.com>

On Mon, 8 Sep 2025 11:16:17 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxml2 to v2.14.5.
> Verified build on all platforms. No issues seen

This pull request has now been integrated.

Changeset: 15c50c20
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/15c50c20b80a9287d5b136a197454eabac604a34
Stats:     50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod

8361893: Update libxml2 to 2.14.5

Reviewed-by: kcr, sykora

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

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

From hmeda at openjdk.org  Mon Sep 15 18:11:15 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 15 Sep 2025 18:11:15 GMT
Subject: Integrated: 8361644 : Update ICU4C to 77.1
In-Reply-To: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
References: <mrGU4xTqSgBUR-nUvtVhY4CqZM4LF3eJzaAJo2huNT0=.164efc2b-9fca-46fc-80d2-57b6bb83cfec@github.com>
Message-ID: <BtO-dNlMIQPhjs2Vw48R4wiMuR77QIlbmTTTvihR_-g=.5b468754-f2f7-4997-9e1e-6739a944a01e@github.com>

On Wed, 3 Sep 2025 11:21:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated icu to v77.1. Verified build on windows, mac and linux. Sanity testing looks fine. No  issues seen.

This pull request has now been integrated.

Changeset: c8cfc89d
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c8cfc89df018abcba9468e6e91ea7ded00f061e7
Stats:     71204 lines in 604 files changed: 48299 ins; 7306 del; 15599 mod

8361644: Update ICU4C to 77.1

Reviewed-by: kcr, sykora

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

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

From angorya at openjdk.org  Mon Sep 15 18:16:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 18:16:13 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v2]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <x0LBzZEAVn_jypjxnfjwXneFvTHb5GDLBupudv2aE2c=.5bcb25ee-2e68-4e5e-b01a-4bb790ad0e53@github.com>

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

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 8336332.failed
 - whitespace
 - revert intentionally failing test
 - 2025
 - fixed utility class name
 - suppress stderr

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/dd43ce99..7b228d42

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

  Stats: 121318 lines in 711 files changed: 60981 ins; 23896 del; 36441 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Mon Sep 15 18:20:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 18:20:41 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v3]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <8BPwE4A8eQP004NQBP0nn0LaV5cHW0SO_n4I6zPEXZg=.719153d0-d7d7-4b97-9bb4-5734a7823bd5@github.com>

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

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

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/7b228d42..cd1b9463

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

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

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

From angorya at openjdk.org  Mon Sep 15 18:51:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 18:51:56 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <L8VZXc3MmyA7Ucr41-QOsIgMYfGCKjM29Tk5NgfcgIc=.495832b2-8d1c-4296-b344-6d4d78c7eef8@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

The fix looks good (macOS 15.6.1 M1)

You could have just edited https://bugs.openjdk.org/browse/JDK-8365827 description instead of creating a whole new ticket.  Save a virtual tree, I say! :-)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1900#pullrequestreview-3225877971

From angorya at openjdk.org  Mon Sep 15 18:55:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 18:55:54 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <Ur7yP9fsO5bJF6_TwIXeM78ltgV26gA2s0J86DoVJjw=.23eb193c-e83a-4f73-8c02-3fbf668f4591@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

Thank you for fixing the issue, @hjohn !

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3293496636

From angorya at openjdk.org  Mon Sep 15 19:25:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 19:25:37 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>

> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
> 
> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Miscellaneous
> 
> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
> 
> ## Questions
> 
> - should we fail the current test with `Assertions.fail()` in case of a mismatch?

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

  moved utility

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/cd1b9463..12e0f6a7

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

  Stats: 24 lines in 14 files changed: 3 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From jhendrikx at openjdk.org  Mon Sep 15 23:16:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 15 Sep 2025 23:16:30 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <L8VZXc3MmyA7Ucr41-QOsIgMYfGCKjM29Tk5NgfcgIc=.495832b2-8d1c-4296-b344-6d4d78c7eef8@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
 <L8VZXc3MmyA7Ucr41-QOsIgMYfGCKjM29Tk5NgfcgIc=.495832b2-8d1c-4296-b344-6d4d78c7eef8@github.com>
Message-ID: <ckJrFq7vubc9tImPgUIF7n5MK4_eBf7lI4IM8sTAd2U=.6a4382a9-1302-4767-b5dd-efb519ba3d6d@github.com>

On Mon, 15 Sep 2025 18:48:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The fix looks good (macOS 15.6.1 M1)
> 
> You could have just edited https://bugs.openjdk.org/browse/JDK-8365827 description instead of creating a whole new ticket. Save a virtual tree, I say! :-)

Sorry about that, I entered a whole new ticket before realizing that other one existed :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3294281929

From angorya at openjdk.org  Mon Sep 15 23:20:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Sep 2025 23:20:31 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <sj1idbYn2xjWwEd81hKqvSbWNcZMUzK8Wjj2PEEij8c=.2d142f33-46e9-4699-9252-cc069a6e5cad@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

no harm done, and thanks for fixing it!  and yours has more technical insight which is good.

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3294291835

From jdv at openjdk.org  Tue Sep 16 11:11:50 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 16 Sep 2025 11:11:50 GMT
Subject: RFR: 8364405: Intermittent MenuDoubleShortcutTest failure on Linux and
 macOS
Message-ID: <TQMg1f0tkZz9p_Y62TRs2f7MNhpwjkwkVJjXmslmM4Q=.69741a5b-c8cd-4744-bdb8-485dc1e21839@github.com>

MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene(on linux) & MenuDoubleShortcutTest > macSceneComesBeforeMenuBar(on macOS) fail intermittently.

In every failure we can see that no Accelerator event in fired `Key press event triggered no actions`.
To initiate accelerator event we use `testKey()` method in this test. `testKey()` method uses asynchronous `Platform.runLater()` to press accelerator shortcut. We have 100ms delay after this asynchronous event to check whether accelerators events are fired, but this is not fool-proof.

So this test is updated to make sure the asynchronous event in `testKey()` is completed by using a `CountDownLatch`. Also i tried removing the delay that we have after `testKey()` call, but it looks like 100ms delay is still needed between keyPress and event callbacks.

Updated test is run 50 times on all platforms and there no intermittent failures seen.

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

Commit messages:
 - Add explicit latch to make sure runLater is honoured

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

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

From sykora at openjdk.org  Tue Sep 16 14:04:45 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Tue, 16 Sep 2025 14:04:45 GMT
Subject: RFR: 8366744 : Update SQLite to 3.50.4
In-Reply-To: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
References: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
Message-ID: <hI4Ak1wtNcBWZ9a5_nPAaTbenKXvG1WjZgfnblP7dqU=.71b9ffe8-0abf-4046-b6e7-72f1cd12976c@github.com>

On Mon, 15 Sep 2025 05:28:52 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated SQLite to v 3.50.4. verified build on all platforms. No issue seen

Builds ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1903#pullrequestreview-3230171073

From arapte at openjdk.org  Tue Sep 16 14:11:09 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 16 Sep 2025 14:11:09 GMT
Subject: RFR: 8366217: Update GStreamer to 1.26.5
In-Reply-To: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
References: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
Message-ID: <6kCHu3BC5SImXUj6JmLCzAicXzlqQWo7YdV4mzprx7U=.b589b496-bec9-4e08-80d9-3288cd9c8e1d@github.com>

On Wed, 10 Sep 2025 19:33:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GStreamer updated to 1.26.5.
> - Tested on all platforms with all supported formats.

LGTM..

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1894#pullrequestreview-3230195145

From kcr at openjdk.org  Tue Sep 16 16:15:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 16:15:22 GMT
Subject: RFR: 8366744 : Update SQLite to 3.50.4
In-Reply-To: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
References: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
Message-ID: <0L2BwWm6PU5bPu-ym-0mDk3Y8CbrGXWXS36LEUzNBGs=.adb0c9bf-4cdb-4446-a9ac-0cd923152cd2@github.com>

On Mon, 15 Sep 2025 05:28:52 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated SQLite to v 3.50.4. verified build on all platforms. No issue seen

Changes look good. Sanity test passed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1903#pullrequestreview-3230740621

From kcr at openjdk.org  Tue Sep 16 16:16:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 16:16:23 GMT
Subject: RFR: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
References: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
Message-ID: <X4WpGfgXHuvuyKbhsnPOqVTkFAJvYSaFpkc6dR5HFEA=.146bd083-3d64-4eb0-a37c-91043aa2a311@github.com>

On Sun, 14 Sep 2025 02:24:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: JavaFX debug builds fail on Linux
> The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.
> 
> Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

LGTM. I see that the test build has passed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1902#pullrequestreview-3230744615

From kcr at openjdk.org  Tue Sep 16 16:17:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 16:17:24 GMT
Subject: RFR: 8367374: JavaFX debug builds fail on Windows
In-Reply-To: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
References: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
Message-ID: <_hSeeOrQp_Eno5mG2WIqcV8nunSkWcXH99bU4I8hkqY=.191ebf2c-fe71-4b15-acbc-2144979b7a1f@github.com>

On Sun, 14 Sep 2025 02:12:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue:  data_as_asm tool fails to generate cpp object from ICU symbols file when webkit builds in debug mode.
> Solution: The ICU third party lib already using MSVC to build , Make ICU build in Release mode.

LGTM. Build passes in debug mode and in normal (release) mode.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1901#pullrequestreview-3230748276

From duke at openjdk.org  Tue Sep 16 17:25:00 2025
From: duke at openjdk.org (Dirk Lemmermann)
Date: Tue, 16 Sep 2025 17:25:00 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <lUFy5vy1t9xf3gkEOC8Ledjpb3_niGkEwQMrHX_NeWQ=.83483e4e-1f13-473c-ad0b-e711126feada@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

Can't wait for this one to get merged. It's the only thing stopping me from upgrading.

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3299681969

From angorya at openjdk.org  Tue Sep 16 17:28:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Sep 2025 17:28:00 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <lUFy5vy1t9xf3gkEOC8Ledjpb3_niGkEwQMrHX_NeWQ=.83483e4e-1f13-473c-ad0b-e711126feada@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
 <lUFy5vy1t9xf3gkEOC8Ledjpb3_niGkEwQMrHX_NeWQ=.83483e4e-1f13-473c-ad0b-e711126feada@github.com>
Message-ID: <PHalhjq4sCTHxFKwrLcndZzaGN_l5XCuVWwn1WB2XhI=.c0a6d7ce-fcca-4a92-bbfe-869e1eb5a586@github.com>

On Tue, 16 Sep 2025 17:22:39 GMT, Dirk Lemmermann <duke at openjdk.org> wrote:

>> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
>> 
>> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
>> 
>> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
>> 
>> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
>> 
>> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
>> 
>> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
>> 
>> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
>> 
>> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.
>
> Can't wait for this one to get merged. It's the only thing stopping me from upgrading.

we need one more review.  join us, @dlemmermann !  :-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3299691441

From kcr at openjdk.org  Tue Sep 16 17:42:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 17:42:35 GMT
Subject: RFR: 8364405: Intermittent MenuDoubleShortcutTest failure on Linux
 and macOS
In-Reply-To: <TQMg1f0tkZz9p_Y62TRs2f7MNhpwjkwkVJjXmslmM4Q=.69741a5b-c8cd-4744-bdb8-485dc1e21839@github.com>
References: <TQMg1f0tkZz9p_Y62TRs2f7MNhpwjkwkVJjXmslmM4Q=.69741a5b-c8cd-4744-bdb8-485dc1e21839@github.com>
Message-ID: <uBk1qfGZTOJYB1HXfNJoxHjXJPmed6Nrw_vKMSF84R0=.f651ca92-ce5c-4ce9-a6b1-ed6e3489c6b7@github.com>

On Tue, 16 Sep 2025 11:05:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene(on linux) & MenuDoubleShortcutTest > macSceneComesBeforeMenuBar(on macOS) fail intermittently.
> 
> In every failure we can see that no Accelerator event in fired `Key press event triggered no actions`.
> To initiate accelerator event we use `testKey()` method in this test. `testKey()` method uses asynchronous `Platform.runLater()` to press accelerator shortcut. We have 100ms delay after this asynchronous event to check whether accelerators events are fired, but this is not fool-proof.
> 
> So this test is updated to make sure the asynchronous event in `testKey()` is completed by using a `CountDownLatch`. Also i tried removing the delay that we have after `testKey()` call, but it looks like 100ms delay is still needed between keyPress and event callbacks.
> 
> Updated test is run 50 times on all platforms and there are no intermittent failures seen.

This looks like the right fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1906#pullrequestreview-3231041658

From kcr at openjdk.org  Tue Sep 16 17:56:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 17:56:24 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <fxibD63goD6V4_1fcgJbHSlYbVeFpEQRmf6vZpjwzwE=.aad85eaf-8a5a-48cf-8a39-e7bb3b456828@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

Looks great. Thanks for fixing this.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1900#pullrequestreview-3231096077

From kcr at openjdk.org  Tue Sep 16 18:12:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 18:12:42 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
Message-ID: <VknenA6UYsdLBtsLPkN9A4Y4AJVCQ3U5Sqys5k-29PQ=.fecdfa0a-157c-49fa-8396-8b742e87fe0e@github.com>

On Mon, 15 Sep 2025 19:25:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headful test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()`.
>> 
>> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Miscellaneous
>> 
>> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
>> 
>> ## Questions
>> 
>> - should we fail the current test with `Assertions.fail()` in case of a mismatch?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved utility

Two general comments before I start looking at the PR:

1. Since you are only addressing the `javafx.base` tests in this PR, please update the JBS title (and PR title) to reflect that.

2. In the description you wrote:

> This PR removes unrelated stderr output in the headful test logs

These are "headless" tests, not headful.

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3299828328

From angorya at openjdk.org  Tue Sep 16 19:20:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Sep 2025 19:20:12 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <VknenA6UYsdLBtsLPkN9A4Y4AJVCQ3U5Sqys5k-29PQ=.fecdfa0a-157c-49fa-8396-8b742e87fe0e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
 <VknenA6UYsdLBtsLPkN9A4Y4AJVCQ3U5Sqys5k-29PQ=.fecdfa0a-157c-49fa-8396-8b742e87fe0e@github.com>
Message-ID: <n_ZB1ZLIW9T4DnYKig5EjUR8x6KrCUjcq9ydAe75_bw=.1b8214c3-9269-4288-ab29-ab1afb6ed6cc@github.com>

On Tue, 16 Sep 2025 18:09:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> 1. Since you are only addressing the `javafx.base`

so that's where it gets complicated: turns out the utility gets used in more tests (graphics, fxml, see https://github.com/openjdk/jfx/pull/1905 ), so two things came up:

1. the utility needs to be moved to another package
2. the utility probably needs to be decoupled from Logging, as it creates unneeded dependency with `--add-exports javafx.base/com.sun.javafx.binding=ALL-UNNAMED` in #1905 
3. perhaps the two PRs need to be merged into one larger one

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3300030743

From almatvee at openjdk.org  Tue Sep 16 19:46:07 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 16 Sep 2025 19:46:07 GMT
Subject: Integrated: 8366217: Update GStreamer to 1.26.5
In-Reply-To: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
References: <PMKXkAUWzvA0oxWrazaPpj0vCxH3BZMlGSvD90RWwec=.bd820cc2-e36a-4158-af4e-cc5713613026@github.com>
Message-ID: <KOuFQb2rRbvBjm-a6CqJJ9r8o5Na9vj1MCUssV0a4r4=.8ed6f3c1-58d5-4ca3-87a5-6d0ad40f073c@github.com>

On Wed, 10 Sep 2025 19:33:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GStreamer updated to 1.26.5.
> - Tested on all platforms with all supported formats.

This pull request has now been integrated.

Changeset: 613bbb14
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/613bbb146e42c0acb86b736e5097b33512841257
Stats:     18884 lines in 166 files changed: 14131 ins; 2041 del; 2712 mod

8366217: Update GStreamer to 1.26.5

Reviewed-by: sykora, arapte

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

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

From kcr at openjdk.org  Tue Sep 16 20:18:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Sep 2025 20:18:24 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
Message-ID: <F1dlgaU6UPCuAPtD_jxvG-yNIr2jJvBI4iogrZBUZl0=.539d068f-2000-4c77-9107-daf975f1c9fb@github.com>

On Mon, 15 Sep 2025 19:25:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` (without failing the test).
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `ErrorLoggingUtility.suppressStderr()` and either `ErrorLoggingUtility.checkStderr()` or `ErrorLoggingUtility.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `ErrorLoggingUtility.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Miscellaneous
>> 
>> For reviewers' convenience, the first commit contains the main change, the second fixes the misspelt name of the utility class, the rest are trivial.
>> 
>> ## Questions
>> 
>> - should we fail the current test with `Assertions.fail()` in case of a mismatch?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved utility

I left a couple quick comments in line. I won't do a thorough review until you decide whether to create a new utility class (which would have the advantage of removing a number of unrelated changes in this PR).

> > 1. Since you are only addressing the `javafx.base`
> 
> so that's where it gets complicated: turns out the utility gets used in more tests (graphics, fxml, see #1905 ), so two things came up:
> 
> 1. the utility needs to be moved to another package
> 2. the utility probably needs to be decoupled from Logging, as it creates unneeded dependency with `--add-exports javafx.base/com.sun.javafx.binding=ALL-UNNAMED` in [8367567: Rework system tests to suppress unrelated stderr output?#1905](https://github.com/openjdk/jfx/pull/1905)

Yes, I think this seems best. Rather than extend the existing javafx.base ErrorLoggingUtility, which is dependent on the (IMO rather hacky) Logging class in javafx.base itself, a separate test utility that just focuses on capturing and parsing stderr and has no dependencies on logging seems best.

> 3. perhaps the two PRs need to be merged into one larger one

Maybe that would be best, although I think it would be OK to keep them separate as long as you do a proof of concept that other modules can use it without needing changes to the exports, etc.

modules/javafx.base/src/test/java/test/util/ErrorLoggingUtility.java line 81:

> 79:     private static PrintStream stderr;
> 80:     private static AccumulatingPrintStream stderrCapture;
> 81:     private static int checked;

This is unused (only ever written) and can be removed.

modules/javafx.base/src/test/java/test/util/ErrorLoggingUtility.java line 127:

> 125:                 stderr.println("Mismatch in thrown exceptions:\n  expected=" + exp + "\n  observed=" + errors);
> 126:                 stderr.println(text);
> 127:             }

A mismatch should fail the test.

modules/javafx.base/src/test/java/test/util/ErrorLoggingUtility.java line 184:

> 182:             // catches lines starting with things like "Exception in thread "main" java.lang.RuntimeException:"
> 183:             "^" +
> 184:             "(?:" +

This might be easier to read and maintain with text blocks.

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3231265800
PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3300210311
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2353364648
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2353453548
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2353554564

From angorya at openjdk.org  Tue Sep 16 20:32:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Sep 2025 20:32:17 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <F1dlgaU6UPCuAPtD_jxvG-yNIr2jJvBI4iogrZBUZl0=.539d068f-2000-4c77-9107-daf975f1c9fb@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
 <F1dlgaU6UPCuAPtD_jxvG-yNIr2jJvBI4iogrZBUZl0=.539d068f-2000-4c77-9107-daf975f1c9fb@github.com>
Message-ID: <EtHvEWS4zyaMTZfl83CGMamRML7A3Qe6a_Qm8hnx4vU=.3dac38ae-3eea-4498-ba64-e9f99211dbe4@github.com>

On Tue, 16 Sep 2025 20:14: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:
>> 
>>   moved utility
>
> modules/javafx.base/src/test/java/test/util/ErrorLoggingUtility.java line 184:
> 
>> 182:             // catches lines starting with things like "Exception in thread "main" java.lang.RuntimeException:"
>> 183:             "^" +
>> 184:             "(?:" +
> 
> This might be easier to read and maintain with text blocks.

it's a complete gibberish as continuous text.  not an easy thing to parse mentally.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2353583759

From almatvee at openjdk.org  Tue Sep 16 21:32:20 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 16 Sep 2025 21:32:20 GMT
Subject: [jfx25u] RFR: 8366217: Update GStreamer to 1.26.5
Message-ID: <7pv4q2PsumP-lPXJArVqOrbj_CiwKIe0BfQmRmNVG94=.3793b6b3-fa40-4af5-8261-b652e8671e2f@github.com>

Clean backport of JDK-8366217.

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

Commit messages:
 - Backport 613bbb146e42c0acb86b736e5097b33512841257

Changes: https://git.openjdk.org/jfx25u/pull/11/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366217
  Stats: 18884 lines in 166 files changed: 14131 ins; 2041 del; 2712 mod
  Patch: https://git.openjdk.org/jfx25u/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/11/head:pull/11

PR: https://git.openjdk.org/jfx25u/pull/11

From almatvee at openjdk.org  Tue Sep 16 22:22:30 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 16 Sep 2025 22:22:30 GMT
Subject: [jfx25u] Integrated: 8366217: Update GStreamer to 1.26.5
In-Reply-To: <7pv4q2PsumP-lPXJArVqOrbj_CiwKIe0BfQmRmNVG94=.3793b6b3-fa40-4af5-8261-b652e8671e2f@github.com>
References: <7pv4q2PsumP-lPXJArVqOrbj_CiwKIe0BfQmRmNVG94=.3793b6b3-fa40-4af5-8261-b652e8671e2f@github.com>
Message-ID: <wm3JjMcxA1Kr00CrAYxryqoEI7yWdWI6JKUshXw4fmQ=.1bfd3344-836c-478c-8cd9-de7faf34093a@github.com>

On Tue, 16 Sep 2025 21:23:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Clean backport of JDK-8366217.

This pull request has now been integrated.

Changeset: 8c3946ee
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/8c3946eecdc0b193cd67b5fdb64f57a22e95f58f
Stats:     18884 lines in 166 files changed: 14131 ins; 2041 del; 2712 mod

8366217: Update GStreamer to 1.26.5

Backport-of: 613bbb146e42c0acb86b736e5097b33512841257

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

PR: https://git.openjdk.org/jfx25u/pull/11

From mfox at openjdk.org  Tue Sep 16 23:05:29 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 16 Sep 2025 23:05:29 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <7BGs1Q29suXCqlENYu6ypHvNxDPzHWyvEg-Vv2SLvxU=.3fdb61e5-9a05-4294-8c38-68a03f24380d@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

Changes look fine to me and are working on macOS 13, 15, and 26.

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

Marked as reviewed by mfox (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1895#pullrequestreview-3231952501

From bdunkley-smith at bigpond.com  Wed Sep 17 01:55:51 2025
From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith)
Date: Wed, 17 Sep 2025 11:55:51 +1000
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
Message-ID: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>

Hi All,

 

Apologies in advance if the terminology in my question is incorrect as I'm
somewhat out of my depth here.

 

I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842 (Video
sometimes does not start when reinitializing in Windows 11) for progress
with interest because I have a legacy JavaFX based application which has
functioned flawlessly for several years, but since upgrading from Win10 to
Win1, there has been intermittent/random failures of videos playing with a
ERROR_MEDIA_INVALID being thrown, even though I've used the same "media"
with success previously and it often runs without error. 

 

So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer
to 1.26.5), I wondered if the update to GStreamer may resolve my issue of
intermittent/random failures of videos.

 

I see that "This pull request has now been integrated." and being ignorant
of how this finds its way into a release of JavaFX, could someone advise me
of how I would know if a version (early release?) is available incorporating
this "fix" and where I can download it from.

 

Thanks,

 

Bryon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/b551ef47/attachment.htm>

From jbhaskar at openjdk.org  Wed Sep 17 02:47:30 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 17 Sep 2025 02:47:30 GMT
Subject: RFR: 8271205: [windows] Intermittent test failure in
 test.javafx.scene.web.MiscellaneousTest::testDOMTimer
Message-ID: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>

Issue: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer
Analysis:
setTimeout call is not a real-time function. it is considered just a minimum delay before the callback is executed. The actual time taken depends

How long it takes to process any messages ahead of the already task in the queue?
Current load on the CPU.
The number of tasks being executed by the JS engine.
current state of OS/Browser.
However, we have to set a minimum timeout value of at least 10 ms, as recommended by Webkit/w3c. Setting value of 1o ms might prevent some un-defined behavior.

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

Commit messages:
 - 8271205: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer

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

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

From jbhaskar at openjdk.org  Wed Sep 17 02:50:55 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 17 Sep 2025 02:50:55 GMT
Subject: RFR: 8271205: [windows] Intermittent test failure in
 test.javafx.scene.web.MiscellaneousTest::testDOMTimer
In-Reply-To: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
References: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
Message-ID: <2ewW5zhSHm3twLsfjMDSb3kBGUo6sgEB2aeIFIkQixI=.e2e47b53-574c-48fb-a8b7-b6c7cce83cbc@github.com>

On Wed, 17 Sep 2025 02:40:43 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer
> Analysis:
> setTimeout call is not a real-time function. it is considered just a minimum delay before the callback is executed. The actual time taken depends
> 
> How long it takes to process any messages ahead of the already task in the queue?
> Current load on the CPU.
> The number of tasks being executed by the JS engine.
> current state of OS/Browser.
> However, we have to set a minimum timeout value of at least 10 ms, as recommended by Webkit/w3c. Setting value of 1o ms might prevent some un-defined behavior.

/ add-reviewer @kevinrushforth @HimaBinduMeda

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

PR Comment: https://git.openjdk.org/jfx/pull/1907#issuecomment-3301030590

From hmeda at openjdk.org  Wed Sep 17 04:26:52 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 04:26:52 GMT
Subject: Integrated: 8366744 : Update SQLite to 3.50.4
In-Reply-To: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
References: <0ehV7O2mPx65Iq915V8JlTL4nthsZiZuW2jLDjwmau8=.919c0805-2148-412d-bcfa-78f609d59065@github.com>
Message-ID: <IEWuwIFHRcjAa8RpixqT6F9jBjsGXe4hYcn6Em4T5SM=.f0de8bba-5bb4-4d39-afde-5fb0f1c4b61f@github.com>

On Mon, 15 Sep 2025 05:28:52 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated SQLite to v 3.50.4. verified build on all platforms. No issue seen

This pull request has now been integrated.

Changeset: 749b5dfb
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/749b5dfbb7387b681155c0769f2c0fe0676d743b
Stats:     3843 lines in 4 files changed: 2063 ins; 554 del; 1226 mod

8366744: Update SQLite to 3.50.4

Reviewed-by: sykora, kcr

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

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

From nlisker at gmail.com  Wed Sep 17 05:40:20 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 17 Sep 2025 08:40:20 +0300
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
In-Reply-To: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
Message-ID: <CA+0ynh-bbnD+2SLF90+QMS6tWnBB1fH-PjjF05AxH_WdrOBRfA@mail.gmail.com>

Hi Bryon,

The fastest ways are building JavaFX and testing it immediately, or waiting
a bit until the early-access build contains that fix (
https://jdk.java.net/javafx26/).

- Nir

On Wed, Sep 17, 2025 at 6:10?AM Bryon Dunkley-Smith <
bdunkley-smith at bigpond.com> wrote:

> Hi All,
>
>
>
> Apologies in advance if the terminology in my question is incorrect as I?m
> somewhat out of my depth here.
>
>
>
> I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842 (Video
> sometimes does not start when reinitializing in Windows 11) for progress
> with interest because I have a legacy JavaFX based application which has
> functioned flawlessly for several years, but since upgrading from Win10 to
> Win1, there has been intermittent/random failures of videos playing with a
> ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media?
> with success previously and it often runs without error.
>
>
>
> So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update
> GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my
> issue of intermittent/random failures of videos.
>
>
>
> I see that ?This pull request has now been integrated.? and being ignorant
> of how this finds its way into a release of JavaFX, could someone advise me
> of how I would know if a version (early release?) is available
> incorporating this ?fix? and where I can download it from.
>
>
>
> Thanks,
>
>
>
> Bryon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/450f28e5/attachment.htm>

From lkostyra at openjdk.org  Wed Sep 17 05:46:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 17 Sep 2025 05:46:53 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v2]
In-Reply-To: <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
 <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
Message-ID: <QyH1wirkIj1Vt4jCYxYeN-iGsdUIDaY4eBBMqD_XUuk=.e4e602c1-cc0d-474b-984a-a81d6299dac7@github.com>

On Tue, 9 Sep 2025 20:26:15 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabled system test on Linux, DECORATED stage is changing height

LGTM, verified on Windows and macOS 15.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1889#pullrequestreview-3232752299

From jhendrikx at openjdk.org  Wed Sep 17 06:30:51 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Sep 2025 06:30:51 GMT
Subject: Integrated: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <mkViuRxCMAA8gbH5VWTtzO2Bbp9IXci4xnsbslvQIA0=.85b7c0d1-78bc-468f-bcaa-d3c148a02f2a@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

This pull request has now been integrated.

Changeset: 7e692bd0
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7e692bd0a577b13a40414adc3ba2a18e02855a40
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8367602: Regression: TabPane with wrapped label calculates wrong initial size

Reviewed-by: angorya, kcr

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

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

From jhendrikx at openjdk.org  Wed Sep 17 07:02:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Sep 2025 07:02:30 GMT
Subject: [jfx25] RFR: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
Message-ID: <7f3X-mmUlQCmUVILvYKnijWc0YQiYoJ9ZzOqw9M_mRQ=.3dfb24db-aa1a-436f-b532-03711485665d@github.com>

8367602: Regression: TabPane with wrapped label calculates wrong initial size

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

Commit messages:
 - Backport 7e692bd0a577b13a40414adc3ba2a18e02855a40

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

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

From jdv at openjdk.org  Wed Sep 17 08:41:03 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 17 Sep 2025 08:41:03 GMT
Subject: Integrated: 8364405: Intermittent MenuDoubleShortcutTest failure on
 Linux and macOS
In-Reply-To: <TQMg1f0tkZz9p_Y62TRs2f7MNhpwjkwkVJjXmslmM4Q=.69741a5b-c8cd-4744-bdb8-485dc1e21839@github.com>
References: <TQMg1f0tkZz9p_Y62TRs2f7MNhpwjkwkVJjXmslmM4Q=.69741a5b-c8cd-4744-bdb8-485dc1e21839@github.com>
Message-ID: <rdhtERvUU8W6i2ZufazGYKvNzGSTU4AWIPBgvdNqi3Q=.12401c3e-d8c5-4b4e-b981-c5bdbd7db408@github.com>

On Tue, 16 Sep 2025 11:05:07 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene(on linux) & MenuDoubleShortcutTest > macSceneComesBeforeMenuBar(on macOS) fail intermittently.
> 
> In every failure we can see that no Accelerator event in fired `Key press event triggered no actions`.
> To initiate accelerator event we use `testKey()` method in this test. `testKey()` method uses asynchronous `Platform.runLater()` to press accelerator shortcut. We have 100ms delay after this asynchronous event to check whether accelerators events are fired, but this is not fool-proof.
> 
> So this test is updated to make sure the asynchronous event in `testKey()` is completed by using a `CountDownLatch`. Also i tried removing the delay that we have after `testKey()` call, but it looks like 100ms delay is still needed between keyPress and event callbacks.
> 
> Updated test is run 50 times on all platforms and there are no intermittent failures seen.

This pull request has now been integrated.

Changeset: d8016e13
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d8016e13a85d77c72d73aa10322e0165abfcafa6
Stats:     5 lines in 1 file changed: 3 ins; 2 del; 0 mod

8364405: Intermittent MenuDoubleShortcutTest failure on Linux and macOS

Reviewed-by: kcr

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

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

From aghaisas at openjdk.org  Wed Sep 17 09:07:43 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 17 Sep 2025 09:07:43 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6
In-Reply-To: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
Message-ID: <tDIFhQtO8vuxuwbNkVNcVvstrjuPnOWndOkdET7tDAc=.26421ecf-5261-408f-95ee-a5fc2acbc477@github.com>

On Mon, 8 Sep 2025 19:49:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - readme.md: 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`
> - TableView page: canvas based cell and row factories
> - Dialog page
> - Progress Bar Page
> - additional scripts in the WritingSystemsDemo
> - pure Swing JTextField/JTextArea window
> - ImageView page
> - AudioClip page
> - events in Drag and Drop page
> - added miscellaneous options
> - TextFlow page: updated hit info visualization, tab stop policy
> - WebView page: added direct html input
> 
> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

Tested newly added tests on macOS. They look good apart from one observation regarding DialogPane test.
I have not tested Eclipse settings as I don't use it.

tests/manual/monkey/src/com/oracle/tools/fx/monkey/pages/DialogPage.java line 120:

> 118: 
> 119:     private Dialog createDialog() {
> 120:         Dialog d = new Dialog();

I am unable to close the created Dialog by pressing red x button on Dialog window on macOS. (This is a problem if Dialog Modality is set to APPLICATION_MODAL - then there is no way to close the dialog and we cannot click on the "Show Dialog" toggle button)

Also, clicking "Show Dialog" button to toggle dialog show and hide is not very intuitive.

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

PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3302037926
PR Review Comment: https://git.openjdk.org/jfx/pull/1887#discussion_r2354805290

From hmeda at openjdk.org  Wed Sep 17 09:17:08 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 09:17:08 GMT
Subject: RFR: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
References: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
Message-ID: <tYRQQxbLHB16QAf2CRsX_onz9nqTaLy2t9VT6Sf62PU=.820c3d47-36f1-4a5e-b08d-0736736d268a@github.com>

On Sun, 14 Sep 2025 02:24:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: JavaFX debug builds fail on Linux
> The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.
> 
> Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

LGTM. Able to verify  HelloWebView using Debug Build.

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

PR Comment: https://git.openjdk.org/jfx/pull/1902#issuecomment-3302073799

From hmeda at openjdk.org  Wed Sep 17 10:55:10 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 10:55:10 GMT
Subject: [jfx25u] RFR: 8361893: Update libxml2 to 2.14.5
Message-ID: <369sgpIq15UJg0nUGOe9EvoqvzmYgYmQISkMXgHYk9c=.395b981f-af01-43fe-be65-73e14d57977e@github.com>

clean backport

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

Commit messages:
 - Backport 15c50c20b80a9287d5b136a197454eabac604a34

Changes: https://git.openjdk.org/jfx25u/pull/12/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=12&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361893
  Stats: 50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod
  Patch: https://git.openjdk.org/jfx25u/pull/12.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/12/head:pull/12

PR: https://git.openjdk.org/jfx25u/pull/12

From kcr at openjdk.org  Wed Sep 17 10:56:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 10:56:50 GMT
Subject: [jfx25] RFR: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
In-Reply-To: <7f3X-mmUlQCmUVILvYKnijWc0YQiYoJ9ZzOqw9M_mRQ=.3dfb24db-aa1a-436f-b532-03711485665d@github.com>
References: <7f3X-mmUlQCmUVILvYKnijWc0YQiYoJ9ZzOqw9M_mRQ=.3dfb24db-aa1a-436f-b532-03711485665d@github.com>
Message-ID: <9VwbgpNkQ0fPT0AxolBhmIpEjAqFbDE6npecaZacunY=.e627071f-7401-4345-bbcc-1ad9e123742a@github.com>

On Wed, 17 Sep 2025 06:56:47 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8367602: Regression: TabPane with wrapped label calculates wrong initial size

The jfx25 branch was the stabilization branch for JavaFX 25, which released yesterday, and is now closed.

Backport this fix to the [jfx25u](https://github.com/openjdk/jfx25u) repo instead.

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

PR Comment: https://git.openjdk.org/jfx/pull/1908#issuecomment-3302437369

From kcr at openjdk.org  Wed Sep 17 10:56:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 10:56:50 GMT
Subject: [jfx25] Withdrawn: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
In-Reply-To: <7f3X-mmUlQCmUVILvYKnijWc0YQiYoJ9ZzOqw9M_mRQ=.3dfb24db-aa1a-436f-b532-03711485665d@github.com>
References: <7f3X-mmUlQCmUVILvYKnijWc0YQiYoJ9ZzOqw9M_mRQ=.3dfb24db-aa1a-436f-b532-03711485665d@github.com>
Message-ID: <2A6h3Ing4kHgZt9rgOI7i5ffaQlD61csslRRCcnLfss=.556162ec-075e-4ae8-8511-4b68d3bd5c76@github.com>

On Wed, 17 Sep 2025 06:56:47 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8367602: Regression: TabPane with wrapped label calculates wrong initial size

This pull request has been closed without being integrated.

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

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

From bdunkley-smith at bigpond.com  Wed Sep 17 11:03:21 2025
From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith)
Date: Wed, 17 Sep 2025 21:03:21 +1000
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
In-Reply-To: <CA+0ynh-bbnD+2SLF90+QMS6tWnBB1fH-PjjF05AxH_WdrOBRfA@mail.gmail.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
 <CA+0ynh-bbnD+2SLF90+QMS6tWnBB1fH-PjjF05AxH_WdrOBRfA@mail.gmail.com>
Message-ID: <003701dc27c2$aececf40$0c6c6dc0$@bigpond.com>

Thank you for your guidance Nir.

 

At this stage building JavaFX is beyond me. So I?ll just monitor the progress of early releases and test once a build contains the fix of interest.

 

From: Nir Lisker <nlisker at gmail.com> 
Sent: Wednesday, 17 September 2025 3:40 PM
To: Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>
Cc: openjfx-dev at openjdk.org
Subject: Re: Availability of JavaFX build incorporating JDK-8366217 fix

 

Hi Bryon,

 

The fastest ways are building JavaFX and testing it immediately, or waiting a bit until the early-access build contains that fix (https://jdk.java.net/javafx26/).

 

- Nir

 

On Wed, Sep 17, 2025 at 6:10?AM Bryon Dunkley-Smith <bdunkley-smith at bigpond.com <mailto:bdunkley-smith at bigpond.com> > wrote:

Hi All,

 

Apologies in advance if the terminology in my question is incorrect as I?m somewhat out of my depth here.

 

I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842 (Video sometimes does not start when reinitializing in Windows 11) for progress with interest because I have a legacy JavaFX based application which has functioned flawlessly for several years, but since upgrading from Win10 to Win1, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media? with success previously and it often runs without error. 

 

So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my issue of intermittent/random failures of videos.

 

I see that ?This pull request has now been integrated.? and being ignorant of how this finds its way into a release of JavaFX, could someone advise me of how I would know if a version (early release?) is available incorporating this ?fix? and where I can download it from.

 

Thanks,

 

Bryon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/9a8eccdb/attachment.htm>

From hmeda at openjdk.org  Wed Sep 17 11:14:25 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 11:14:25 GMT
Subject: RFR: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
References: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
Message-ID: <g6Weg76G6IDFL7rOYIVfa1rF_BwpFHoyw1cdIZNTX7k=.6a69cd75-dc24-485d-a12f-4d0213cda89d@github.com>

On Sun, 14 Sep 2025 02:24:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: JavaFX debug builds fail on Linux
> The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.
> 
> Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

Marked as reviewed by hmeda (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1902#pullrequestreview-3233920255

From kcr at openjdk.org  Wed Sep 17 11:19:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 11:19:20 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
Message-ID: <Swa-QBhQ4aTGgc_yc5tLxnOX8br67Uim-JPJLDAGkDE=.e3271035-78f6-46fb-be98-ee5a605a455b@github.com>

On Sat, 13 Sep 2025 17:54:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix for regression in TabPane size calculation caused by https://bugs.openjdk.org/browse/JDK-8350149 (#1723) between versions 25-ea+8 and 25-ea+10
> 
> In Region several height calculations functions were altered to match the behavior and options of their horizontal counterparts to solve discrepancies between the behavior of vertical biased layouts and horizontal biased layouts, which other than their axis, should behave identical.
> 
> The height calculations would take a width provided by the caller, but if unavailable (set to -1) and the child was biased, it would just automatically query the child's preferred width and use that as the dependent width.
> 
> In contrast, the horizontal functions would only do this if a height was provided by the caller (not -1), and would only override this value if the property fillHeight was false (in which case it would query the child's height directly).
> 
> With the change in [JDK-8350149](https://bugs.openjdk.org/browse/JDK-8350149), the vertical calculations operate the same as the horizontal ones, as this is generally more flexible. However, the automatic behavior to query the child's size if the dependent size given was set to -1 is no longer there (as this behavior isn't how biased calculations should work).
> 
> The TabPaneSkin has chosen to directly call several width/height functions without obeying the content bias contract, which says that in case of bias, the dependent size must be calculated first and then passed to the size calculation one is interested in.
> 
> (As an aside, if TabPaneSkin had elected to put all tabs in a single StackPane, then StackPane would have correctly done these calculations, but digging into why it is done this way, with each individual Tab wrapped in its own Node (also a StackPane), is a bit out of scope for this fix).
> 
> As it is, TabPaneSkin should check the bias of the tab it is doing calculations for, and if biased, should first query the dependent size before triggering the size calculation it is interested in.

> /backport jfx jfx25u
> ...
> /backport jfx jfx25

That should be: `/backport jfx25u`, since jfx25u is a repo, not a branch in the jfx repo.

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3302514343

From jbhaskar at openjdk.org  Wed Sep 17 11:19:21 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 17 Sep 2025 11:19:21 GMT
Subject: Integrated: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
References: <c1P_XZ-u5MZ7RlxrT4e800Mtwi2Bg4VIvEEa_kb41tw=.eb4d5b5c-3bf2-4275-93dd-93d153447102@github.com>
Message-ID: <IaEYkGNJ7LedJ825tQ3DLPK7fKWsnN7vtYogIs3vucA=.1aebcf9a-0870-4b2e-a1c1-1b60e9c09ea9@github.com>

On Sun, 14 Sep 2025 02:24:20 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: JavaFX debug builds fail on Linux
> The failure is permission issue on javascript core scripts that generates built in functions, the script has no write and execute permission permission.
> 
> Solution : Use copy of scripts not from JavaScriptCore source with right permission  ( OWNER_EXECUTE).

This pull request has now been integrated.

Changeset: 35c1e39c
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/35c1e39cddc6c3d15118b61f99d67f2aba7641c4
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8329874: JavaFX debug builds fail on Linux

Reviewed-by: kcr, hmeda

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

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

From jhendrikx at openjdk.org  Wed Sep 17 11:37:35 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Sep 2025 11:37:35 GMT
Subject: RFR: 8367602: Regression: TabPane with wrapped label calculates
 wrong initial size
In-Reply-To: <Swa-QBhQ4aTGgc_yc5tLxnOX8br67Uim-JPJLDAGkDE=.e3271035-78f6-46fb-be98-ee5a605a455b@github.com>
References: <wjMm8rU-yInrfip-JFhWiAOp2AEyOsI5EYdYm4XHu7g=.d5400a20-6db1-436a-ac46-4488d3f4eca9@github.com>
 <Swa-QBhQ4aTGgc_yc5tLxnOX8br67Uim-JPJLDAGkDE=.e3271035-78f6-46fb-be98-ee5a605a455b@github.com>
Message-ID: <V0FNhLdSj0LmW4stSrlZts4UHqrTk1H88-vD3eDVt60=.328a1654-fbc1-4716-8576-a0e6267ab030@github.com>

On Wed, 17 Sep 2025 11:16:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > /backport jfx jfx25u
> > ...
> > /backport jfx jfx25
> 
> That should be: `/backport jfx25u`, since jfx25u is a repo, not a branch in the jfx repo.

Ah, that explains it, thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1900#issuecomment-3302577463

From kevin.rushforth at oracle.com  Wed Sep 17 11:44:24 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 17 Sep 2025 04:44:24 -0700
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
In-Reply-To: <003701dc27c2$aececf40$0c6c6dc0$@bigpond.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
 <CA+0ynh-bbnD+2SLF90+QMS6tWnBB1fH-PjjF05AxH_WdrOBRfA@mail.gmail.com>
 <003701dc27c2$aececf40$0c6c6dc0$@bigpond.com>
Message-ID: <72a47ba7-cf6c-4d85-9ed7-3343f1558e13@oracle.com>

It will likely be in this week's JavaFX 26-ea build 8. Once it is, you 
can download it from jdk.java.net using the URL Nir sent.

Btw, Alexander Matveev can comment on the likelihood of the GStreamer 
update fixing your problem. It seems unlikely to me, but let's see what 
he says.

-- Kevin


On 9/17/2025 4:03 AM, Bryon Dunkley-Smith wrote:
>
> Thank you for your guidance Nir.
>
> At this stage building JavaFX is beyond me. So I?ll just monitor the 
> progress of early releases and test once a build contains the fix of 
> interest.
>
> *From:*Nir Lisker <nlisker at gmail.com>
> *Sent:* Wednesday, 17 September 2025 3:40 PM
> *To:* Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>
> *Cc:* openjfx-dev at openjdk.org
> *Subject:* Re: Availability of JavaFX build incorporating JDK-8366217 fix
>
> Hi Bryon,
>
> The fastest ways are building JavaFX and testing it immediately, or 
> waiting a bit until the early-access build contains that fix 
> (https://jdk.java.net/javafx26/).
>
> - Nir
>
> On Wed, Sep 17, 2025 at 6:10?AM Bryon Dunkley-Smith 
> <bdunkley-smith at bigpond.com> wrote:
>
>     Hi All,
>
>     Apologies in advance if the terminology in my question is
>     incorrect as I?m somewhat out of my depth here.
>
>     I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842
>     (Video sometimes does not start when reinitializing in Windows 11)
>     for progress with interest because I have a legacy JavaFX based
>     application which has functioned flawlessly for several years, but
>     since upgrading from Win10 to Win1, there has been
>     intermittent/random failures of videos playing with a
>     ERROR_MEDIA_INVALID being thrown, even though I?ve used the same
>     ?media? with success previously and it often runs without error.
>
>     So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update
>     GStreamer to 1.26.5), I wondered if the update to GStreamer may
>     resolve my issue of intermittent/random failures of videos.
>
>     I see that ?This pull request has now been integrated.? and being
>     ignorant of how this finds its way into a release of JavaFX, could
>     someone advise me of how I would know if a version (early
>     release?) is available incorporating this ?fix? and where I can
>     download it from.
>
>     Thanks,
>
>     Bryon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/dabd0e85/attachment-0001.htm>

From hmeda at openjdk.org  Wed Sep 17 11:53:18 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 11:53:18 GMT
Subject: [jfx25u] Integrated: 8361893: Update libxml2 to 2.14.5
In-Reply-To: <369sgpIq15UJg0nUGOe9EvoqvzmYgYmQISkMXgHYk9c=.395b981f-af01-43fe-be65-73e14d57977e@github.com>
References: <369sgpIq15UJg0nUGOe9EvoqvzmYgYmQISkMXgHYk9c=.395b981f-af01-43fe-be65-73e14d57977e@github.com>
Message-ID: <SRiC-3gWMl9nsnpGjifj4ab5WQz-CMBAzIuR0v2nbLY=.ea6b7d58-5f99-4ad0-aeb7-29111db65cde@github.com>

On Wed, 17 Sep 2025 10:48:26 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> clean backport

This pull request has now been integrated.

Changeset: 8c84c38a
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/8c84c38a8d83e4ead9535956d5710be09b5b6d6a
Stats:     50107 lines in 105 files changed: 12675 ins; 16590 del; 20842 mod

8361893: Update libxml2 to 2.14.5

Backport-of: 15c50c20b80a9287d5b136a197454eabac604a34

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

PR: https://git.openjdk.org/jfx25u/pull/12

From jhendrikx at openjdk.org  Wed Sep 17 12:14:04 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Sep 2025 12:14:04 GMT
Subject: [jfx25u] RFR: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
Message-ID: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>

8367602: Regression: TabPane with wrapped label calculates wrong initial size

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

Commit messages:
 - Backport 7e692bd0a577b13a40414adc3ba2a18e02855a40

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

PR: https://git.openjdk.org/jfx25u/pull/13

From kcr at openjdk.org  Wed Sep 17 13:02:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 13:02:57 GMT
Subject: [jfx25u] RFR: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
In-Reply-To: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
References: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
Message-ID: <dpdDpFiw4HoUtSFDbX8d4AB9QDUr5UTqnk0S61y3_io=.c87c807e-731d-4e1a-9b56-9ff20dfda199@github.com>

On Wed, 17 Sep 2025 12:08:11 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8367602: Regression: TabPane with wrapped label calculates wrong initial size

@hjohn For JavaFX update releases such as jfx25u, you need to request Maintainer approval by using the `/approval request` command. Then I'll approve it.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/13#issuecomment-3302897772

From kcr at openjdk.org  Wed Sep 17 14:20:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 14:20:09 GMT
Subject: [jfx25u] RFR: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
In-Reply-To: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
References: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
Message-ID: <6lcgS_AK4_EOpmOvYAakArG4vKFp72cE_vxR3u9HTZc=.5be29f7b-a010-4d41-a4d4-9bbe330f88fe@github.com>

On Wed, 17 Sep 2025 12:08:11 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8367602: Regression: TabPane with wrapped label calculates wrong initial size

Approved to integrate.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/13#issuecomment-3303234128

From ltorokrl at gmail.com  Wed Sep 17 14:56:39 2025
From: ltorokrl at gmail.com (=?UTF-8?B?TGFkaXNsYXYgVMO2csO2aw==?=)
Date: Wed, 17 Sep 2025 16:56:39 +0200
Subject: Generated API Doc for JavaFX 25 - Deprecated Preview Features
Message-ID: <CA+nmJzKAcAUzmp65Y5pyMDHtewnHXK4KcHe8+VP5+gmY5-y38A@mail.gmail.com>

Public generated API documentation for JavaFX 25 has set ?Deprecated.? for
Preview Features, for example class javafx.scene.layout.HeaderBar and other
preview classes.

Doc. for Java SE 25 API has for Preview Features other, as for example
?StableValue is a preview API of the Java platform.?

Link for public doc.: https://openjfx.io/javadoc/25
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/5371f711/attachment.htm>

From arapte at openjdk.org  Wed Sep 17 15:21:37 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 17 Sep 2025 15:21:37 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6
In-Reply-To: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
Message-ID: <UXWl4rHeNOXFBjU6EQpzj_elGgrSTnoaNoc5zS9yemA=.50e8164e-e04c-4fe7-8b7c-e0a1c8f4eb0a@github.com>

On Mon, 8 Sep 2025 19:49:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - readme.md: 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`
> - TableView page: canvas based cell and row factories
> - Dialog page
> - Progress Bar Page
> - additional scripts in the WritingSystemsDemo
> - pure Swing JTextField/JTextArea window
> - ImageView page
> - AudioClip page
> - events in Drag and Drop page
> - added miscellaneous options
> - TextFlow page: updated hit info visualization, tab stop policy
> - WebView page: added direct html input
> 
> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

Tested on MacOS. Looks good, but with two issues.
1. With Dialog page, same as what @aghaisas observed.
2. With ImageView page: The Monkey tester app window can become unusable if Image size is large 4096 x 4096. It needs to delete `~/.MonkeyTester/ui-settings.properties` file to regain the control over app.
Steps:
- Launch MonkeyTester
- Navigate to ImageView
- Change Image to 4096 x 4096
- The Image displayed is too large to observe both side panes.
<img width="1063" height="686" alt="Screenshot-MonkeyTester-ImageView" src="https://github.com/user-attachments/assets/c5a552b5-f5db-4676-b590-c7c0074cef10" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3303498446

From hmeda at openjdk.org  Wed Sep 17 15:49:34 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 15:49:34 GMT
Subject: [jfx25u] RFR: 8361644: Update ICU4C to 77.1
Message-ID: <s5cu1EZi08vkSNtAY1hhQi2tTYiqTVHKKNwEYsztHdc=.302efeb4-78c5-44b7-96ca-f0fb4de43f6d@github.com>

Clean Backport

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

Commit messages:
 - Backport c8cfc89df018abcba9468e6e91ea7ded00f061e7

Changes: https://git.openjdk.org/jfx25u/pull/14/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361644
  Stats: 71204 lines in 604 files changed: 48299 ins; 7306 del; 15599 mod
  Patch: https://git.openjdk.org/jfx25u/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/14/head:pull/14

PR: https://git.openjdk.org/jfx25u/pull/14

From hmeda at openjdk.org  Wed Sep 17 16:01:21 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 16:01:21 GMT
Subject: RFR: 8367374: JavaFX debug builds fail on Windows
In-Reply-To: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
References: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
Message-ID: <nkMtZlp3e6CxMdg6aKTZtYUvl2mv7NPxX1J41rUbKzA=.8760cfc4-0936-4400-b807-680bfe5fce53@github.com>

On Sun, 14 Sep 2025 02:12:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue:  data_as_asm tool fails to generate cpp object from ICU symbols file when webkit builds in debug mode.
> Solution: The ICU third party lib already using MSVC to build , Make ICU build in Release mode.

Marked as reviewed by hmeda (Committer).

Changes look fine. Verified debug build on local windows platform

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

PR Review: https://git.openjdk.org/jfx/pull/1901#pullrequestreview-3235186585
PR Comment: https://git.openjdk.org/jfx/pull/1901#issuecomment-3303647308

From jbhaskar at openjdk.org  Wed Sep 17 16:07:25 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 17 Sep 2025 16:07:25 GMT
Subject: Integrated: 8367374: JavaFX debug builds fail on Windows
In-Reply-To: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
References: <OgcaZkVpc3w2i0n7uQ2pCWlgjlsul9o3z5LV0TMNkK4=.b5c3ad91-a986-41a0-9bb5-9eb30696e3d3@github.com>
Message-ID: <3f_Q6bsaFH1fysJzS0k69KFQhM1jIaTH4cCyNmuGwwA=.4b9a6e12-577b-4c0c-9928-6b207ef732a3@github.com>

On Sun, 14 Sep 2025 02:12:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue:  data_as_asm tool fails to generate cpp object from ICU symbols file when webkit builds in debug mode.
> Solution: The ICU third party lib already using MSVC to build , Make ICU build in Release mode.

This pull request has now been integrated.

Changeset: 49bece0a
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/49bece0a566e23b897421d248f2a7aa14aefa58f
Stats:     9 lines in 1 file changed: 2 ins; 0 del; 7 mod

8367374: JavaFX debug builds fail on Windows

Reviewed-by: kcr, hmeda

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

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

From jhendrikx at openjdk.org  Wed Sep 17 17:14:33 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 Sep 2025 17:14:33 GMT
Subject: [jfx25u] Integrated: 8367602: Regression: TabPane with wrapped label
 calculates wrong initial size
In-Reply-To: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
References: <o7cfF549y9XFpBs5O-NT70tJipUQ9Tp18VigC8UG9mA=.5ebde19c-4941-48f7-85fc-909344235130@github.com>
Message-ID: <maOFwuUdTyMh_g-2bqim-5zoUMdtLRV10qyjzhqvRaY=.613554cb-c5c4-4fee-91a7-55ce6e9c7596@github.com>

On Wed, 17 Sep 2025 12:08:11 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8367602: Regression: TabPane with wrapped label calculates wrong initial size

This pull request has now been integrated.

Changeset: 5082157a
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/5082157a05a04d939c4574a5c818aa39a3e37772
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8367602: Regression: TabPane with wrapped label calculates wrong initial size

Backport-of: 7e692bd0a577b13a40414adc3ba2a18e02855a40

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

PR: https://git.openjdk.org/jfx25u/pull/13

From hmeda at openjdk.org  Wed Sep 17 17:55:12 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 17 Sep 2025 17:55:12 GMT
Subject: [jfx25u] Integrated: 8361644: Update ICU4C to 77.1
In-Reply-To: <s5cu1EZi08vkSNtAY1hhQi2tTYiqTVHKKNwEYsztHdc=.302efeb4-78c5-44b7-96ca-f0fb4de43f6d@github.com>
References: <s5cu1EZi08vkSNtAY1hhQi2tTYiqTVHKKNwEYsztHdc=.302efeb4-78c5-44b7-96ca-f0fb4de43f6d@github.com>
Message-ID: <xSn3Mw-p6Mcc9CyQ2Zr2mXR3PJX8mn9sLl3C2dJshMo=.9b857c09-725f-4ed7-b8ee-7ea7e9e952fc@github.com>

On Wed, 17 Sep 2025 15:41:31 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 13d3902d
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/13d3902dcb3bd86950adef843f23d09c971cf80e
Stats:     71204 lines in 604 files changed: 48299 ins; 7306 del; 15599 mod

8361644: Update ICU4C to 77.1

Backport-of: c8cfc89df018abcba9468e6e91ea7ded00f061e7

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

PR: https://git.openjdk.org/jfx25u/pull/14

From mfox at openjdk.org  Wed Sep 17 18:04:21 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 17 Sep 2025 18:04:21 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v60]
In-Reply-To: <hVHQezNT5ebKI_KV8finuSGLZRmYom-BB0UMIuo3G70=.715cf799-86fb-4c1e-86d1-314ebfd62a9c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@github.com>
 <hVHQezNT5ebKI_KV8finuSGLZRmYom-BB0UMIuo3G70=.715cf799-86fb-4c1e-86d1-314ebfd62a9c@github.com>
Message-ID: <ZzmOr-_e5bmpN3eIbXihvTtim6iM7YSNKJ1Tp3k823E=.be1a9a1d-6690-439a-b55f-7fcceafdb200@github.com>

On Wed, 10 Sep 2025 15:43:31 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> I've been going through the review and tests here, I still have some more code to review but I did notice there are some test failures on Windows:

I've tracked down one issue with these tests. Some of them try to verify where the top stage is by sampling from a fixed location in screen coordinates, typically calling `getColor(100, 100)`. Depending on the platform and stage style this might sample a pixel from the Label in the middle of the top stage's scene. This happens on Windows when the top stage's style is EXTENDED. This doesn't happen on macOS because the top stage gets shifted down to avoid the menu bar (the test tries to position the top stage at y = 0 but it ends up at y = 25 instead).

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3304041970

From angorya at openjdk.org  Wed Sep 17 18:39:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 18:39:05 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
Message-ID: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>

Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.

Added corresponding gradle option `TEST_SCREENSHOT`.

The function is disabled by default for privacy reasons.

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

Commit messages:
 - test.screenshot system property

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

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

From angorya at openjdk.org  Wed Sep 17 19:55:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 19:55:26 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v7]
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <jIIhr-XoTnvWshJ9040n4J-qdd3Nesns8pL08u8hlec=.30a10d04-c5a5-44b4-99ff-431ea8f3d3b1@github.com>

> 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
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2"...

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 11 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - 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
 - ... and 1 more: https://git.openjdk.org/jfx/compare/84bb2bc7...2e8848ef

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/84b32e51..2e8848ef

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

  Stats: 145207 lines in 1110 files changed: 77884 ins; 26539 del; 40784 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 kcr at openjdk.org  Wed Sep 17 20:12:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 20:12:28 GMT
Subject: RFR: 8367898: Skip StageFocusTest on Linux
Message-ID: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>

Skip `StageFocusTest` on Linux until [JDK-8367893](https://bugs.openjdk.org/browse/JDK-8367893) is fixed.

Also tested on macOS and Windows to verify that the test is still run.

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

Commit messages:
 - 8367898: Skip StageFocusTest on Linux

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

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

From kcr at openjdk.org  Wed Sep 17 20:16:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 20:16:59 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <KPCbdcb8QbaFk1-RGS5KyJxaNy1YYGAHZ5wHF3HLMFM=.2c3fc3c1-639e-4f66-8c8d-f47510960b52@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

The build / code changes look good. I'll run a few tests then approve.

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

PR Review: https://git.openjdk.org/jfx/pull/1910#pullrequestreview-3236122230

From alexander.matveev at oracle.com  Wed Sep 17 20:35:45 2025
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 17 Sep 2025 20:35:45 +0000
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
In-Reply-To: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
Message-ID: <DM3PPFC82B87818ECC8A922B85853C766CA9917A@DM3PPFC82B87818.namprd10.prod.outlook.com>

Hi Bryon,

No, JDK-8366217 does not resolve JDK-8305842. JDK-8305842 is still reproducible on Windows 11 with JDK-8366217.

Thanks,
Alexander

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>
Date: Tuesday, September 16, 2025 at 6:56?PM
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
Hi All,

Apologies in advance if the terminology in my question is incorrect as I?m somewhat out of my depth here.

I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842 (Video sometimes does not start when reinitializing in Windows 11) for progress with interest because I have a legacy JavaFX based application which has functioned flawlessly for several years, but since upgrading from Win10 to Win1, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media? with success previously and it often runs without error.

So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my issue of intermittent/random failures of videos.

I see that ?This pull request has now been integrated.? and being ignorant of how this finds its way into a release of JavaFX, could someone advise me of how I would know if a version (early release?) is available incorporating this ?fix? and where I can download it from.

Thanks,

Bryon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250917/a4cec224/attachment.htm>

From angorya at openjdk.org  Wed Sep 17 20:36:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 20:36:47 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6 [v2]
In-Reply-To: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
Message-ID: <Cky0Y4FpR-Ga6LyeCzIq_KrdxfCnKu4Qyp87LnyGXIA=.a3378c4d-5881-44c5-b4be-49dd6131f5f2@github.com>

> Further additions to the MonkeyTester application:
> 
> - readme.md: 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`
> - TableView page: canvas based cell and row factories
> - Dialog page
> - Progress Bar Page
> - additional scripts in the WritingSystemsDemo
> - pure Swing JTextField/JTextArea window
> - ImageView page
> - AudioClip page
> - events in Drag and Drop page
> - added miscellaneous options
> - TextFlow page: updated hit info visualization, tab stop policy
> - WebView page: added direct html input
> 
> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

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 eight additional commits since the last revision:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8353743.monkey
 - Merge branch 'master' into 8353743.monkey
 - spelling
 - jdk jfx 24
 - whitespace
 - whitespace
 - sync up with standalone repo

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1887/files
  - new: https://git.openjdk.org/jfx/pull/1887/files/c5c0c934..05af0a7e

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

  Stats: 144260 lines in 891 files changed: 77362 ins; 26502 del; 40396 mod
  Patch: https://git.openjdk.org/jfx/pull/1887.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1887/head:pull/1887

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

From angorya at openjdk.org  Wed Sep 17 20:43:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 20:43:00 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6
In-Reply-To: <tDIFhQtO8vuxuwbNkVNcVvstrjuPnOWndOkdET7tDAc=.26421ecf-5261-408f-95ee-a5fc2acbc477@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
 <tDIFhQtO8vuxuwbNkVNcVvstrjuPnOWndOkdET7tDAc=.26421ecf-5261-408f-95ee-a5fc2acbc477@github.com>
Message-ID: <U7jdKszWWwBSzff_Yff5q2GplTl0k2Kgx2Qx9suAiJI=.f6942107-9b13-46b4-a860-a2f74e4d90b2@github.com>

On Wed, 17 Sep 2025 09:04:12 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Further additions to the MonkeyTester application:
>> 
>> - readme.md: 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`
>> - TableView page: canvas based cell and row factories
>> - Dialog page
>> - Progress Bar Page
>> - additional scripts in the WritingSystemsDemo
>> - pure Swing JTextField/JTextArea window
>> - ImageView page
>> - AudioClip page
>> - events in Drag and Drop page
>> - added miscellaneous options
>> - TextFlow page: updated hit info visualization, tab stop policy
>> - WebView page: added direct html input
>> 
>> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).
>
> Tested newly added tests on macOS. They look good apart from one observation regarding DialogPane test.
> I have not tested Eclipse settings as I don't use it.

Thank you for the comments @aghaisas @arapte !

Made the following changes:
1. added the button bar with a Cancel button to the dialog (without it the dialog won't get closed)
2. the "Show Dialog" button now changes to "Hide Dialog" when the dialog is visible
3. added "Clear Image" popup menu item to the context menu on the ImageView page.  I don't want to remove the large image option.

Speaking of messing up the setting such that the UI becomes unusable - I was thinking about a global menu option to reset the properties to their default values in the next iteration of the monkey tester.

Also, @kevinrushforth once suggested a function to export/import the properties so they can be reproduced exactly (for example, they can be attached to a bug report).  I've been thinking about it for a while and it seems like a nice improvement - if only we had APIs to query the default value of properties somehow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3304501084

From kcr at openjdk.org  Wed Sep 17 20:48:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 20:48:34 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <rpD6I5T9c_oU9roXEUSPrlmtFTbRiWDQqkDRUdz7A3Q=.5a74ed9d-31f5-4f7f-af6b-0d35a4f9ac61@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

@jayathirthrao Can you also review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1910#issuecomment-3304512423

From kcr at openjdk.org  Wed Sep 17 20:57:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 20:57:48 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <XTrLO_CX57f3WQg7PLHyiGx1OrZPvvMzQYhnYcezu6A=.f27b3cf9-4623-489f-8c6d-b53f992f451e@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1910#pullrequestreview-3236243648

From angorya at openjdk.org  Wed Sep 17 21:41:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 21:41:45 GMT
Subject: RFR: 8367898: Skip StageFocusTest on Linux
In-Reply-To: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
References: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
Message-ID: <QBXDNjExpZFTuE6mzi8pqtatbE2xNxk26TCeOo-Cot0=.ac011e22-53a7-4af2-b7fd-5f926d58bc1c@github.com>

On Wed, 17 Sep 2025 15:00:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Skip `StageFocusTest` on Linux until [JDK-8367893](https://bugs.openjdk.org/browse/JDK-8367893) is fixed.
> 
> Also tested on macOS and Windows to verify that the test is still run.

ship it!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1909#pullrequestreview-3236358332

From kcr at openjdk.org  Wed Sep 17 21:47:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 21:47:27 GMT
Subject: RFR: 8367898: Skip StageFocusTest on Linux
In-Reply-To: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
References: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
Message-ID: <h8aoisUBmzyGliaEtAB-wa1Rq7ihUPb4Lua7VyvDAtY=.0b6ce8c3-cb92-41dd-a011-fc7f6d1b2df3@github.com>

On Wed, 17 Sep 2025 15:00:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Skip `StageFocusTest` on Linux until [JDK-8367893](https://bugs.openjdk.org/browse/JDK-8367893) is fixed.
> 
> Also tested on macOS and Windows to verify that the test is still run.

Since this is just skipping a problematic test, I waive the usual 24 hour waiting period.

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

PR Comment: https://git.openjdk.org/jfx/pull/1909#issuecomment-3304650586

From kcr at openjdk.org  Wed Sep 17 21:47:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 21:47:27 GMT
Subject: Integrated: 8367898: Skip StageFocusTest on Linux
In-Reply-To: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
References: <0pOnNW_r_kT3FOJ2Mb5vmyHyRsBfEHEX-8JP9M7Afi0=.2b271532-41d4-4602-96d3-deb451c2f1bd@github.com>
Message-ID: <8XTY9i-HAmol_4ussdbS7fE36TAPc7oP-rnx_OOJofQ=.8812bcb1-b218-4da5-ab6c-4d881e469899@github.com>

On Wed, 17 Sep 2025 15:00:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Skip `StageFocusTest` on Linux until [JDK-8367893](https://bugs.openjdk.org/browse/JDK-8367893) is fixed.
> 
> Also tested on macOS and Windows to verify that the test is still run.

This pull request has now been integrated.

Changeset: c95cdcdc
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c95cdcdc9cd8b3070e8076ea91234772d6a21331
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8367898: Skip StageFocusTest on Linux

Reviewed-by: angorya

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

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

From kevin.rushforth at oracle.com  Wed Sep 17 23:05:14 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 17 Sep 2025 16:05:14 -0700
Subject: JavaFX 25 General Availability
In-Reply-To: <4f1e2186-77b1-4ddf-a411-a6753cb9b577@oracle.com>
References: <4f1e2186-77b1-4ddf-a411-a6753cb9b577@oracle.com>
Message-ID: <5c6f368f-1a46-4a85-bb33-285caa2e7d6a@oracle.com>

We released JavaFX 25 yesterday in connection with the JDK 25 release 
[1]. Binaries from Oracle can be download from jdk.java.net at:

https://jdk.java.net/javafx25/

They can also be downloaded from:

https://openjfx.io/

Release notes are available here:

https://github.com/openjdk/jfx/blob/jfx25/doc-files/release-notes-25.md

-- Kevin

[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-September/010483.html


From angorya at openjdk.org  Wed Sep 17 23:07:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 23:07:13 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v5]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <4ZEScKI8ZncLDY3W5PTlLjVNV-uYsXRbzSqqM_GhPRM=.b4a5db0b-6ba7-460c-a681-052ba610e740@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> - fixed ErrorLoggingUtiltity name

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 21 additional commits since the last revision:

 - snapshot 1 test
 - Merge remote-tracking branch 'origin/master' into 8367567.expected
 - expected
 - single exit common
 - message
 - whitespace
 - launcher test
 - revert add exports
 - decouple logging
 - test.javafx.util
 - ... and 11 more: https://git.openjdk.org/jfx/compare/c381e291...98f60999

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/12e0f6a7..98f60999

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

  Stats: 23516 lines in 205 files changed: 16622 ins; 2845 del; 4049 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Wed Sep 17 23:07:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 17 Sep 2025 23:07:14 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v4]
In-Reply-To: <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sJtQSNa9gWzlVezx1VdgWeOex3ruxauHwUSqaufFc1M=.9a1f3fc0-0df2-4230-aa7b-620dc1de78ea@github.com>
Message-ID: <0FbtgUzPIIHSjKMuFKHb12XlT0N60c11QARRBfv6QoI=.1e8a946d-248d-4e38-8705-394f5899d63b@github.com>

On Mon, 15 Sep 2025 19:25:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> - fixed ErrorLoggingUtiltity name
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved utility

thanks for suggestions!  I'll revert back to DRAFT since there will be more structural changes, then we'll see if we can separate the two PRs or combine them.

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3300257750

From kcr at openjdk.org  Wed Sep 17 23:31:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 23:31:35 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v5]
In-Reply-To: <4ZEScKI8ZncLDY3W5PTlLjVNV-uYsXRbzSqqM_GhPRM=.b4a5db0b-6ba7-460c-a681-052ba610e740@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <4ZEScKI8ZncLDY3W5PTlLjVNV-uYsXRbzSqqM_GhPRM=.b4a5db0b-6ba7-460c-a681-052ba610e740@github.com>
Message-ID: <xfimJHP5YibKEjbtjTd3iV4ccp5FnRp5J5kYtzyQkMI=.594afae0-8a8a-41bb-b2a5-7eb6b150a691@github.com>

On Wed, 17 Sep 2025 23:07:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> - fixed ErrorLoggingUtiltity name
>
> 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 21 additional commits since the last revision:
> 
>  - snapshot 1 test
>  - Merge remote-tracking branch 'origin/master' into 8367567.expected
>  - expected
>  - single exit common
>  - message
>  - whitespace
>  - launcher test
>  - revert add exports
>  - decouple logging
>  - test.javafx.util
>  - ... and 11 more: https://git.openjdk.org/jfx/compare/a6915386...98f60999

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ErrorLoggingUtility.java line 36:

> 34: import com.sun.javafx.logging.PlatformLogger.Level;
> 35: 
> 36: public class ErrorLoggingUtility {

I see you left in the name change to `ErrorLoggingUtility`. I was hoping you'd revert that along with the other changes to this file, since they are now unrelated and make the PR much larger to review. Yes, I know it's a mechanical change, but I find it hard to see what has "really" changed now.

Suggestion: revert the name change to this utility, since it is no longer relevant.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2356991012

From kcr at openjdk.org  Wed Sep 17 23:34:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 17 Sep 2025 23:34:51 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v5]
In-Reply-To: <xfimJHP5YibKEjbtjTd3iV4ccp5FnRp5J5kYtzyQkMI=.594afae0-8a8a-41bb-b2a5-7eb6b150a691@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <4ZEScKI8ZncLDY3W5PTlLjVNV-uYsXRbzSqqM_GhPRM=.b4a5db0b-6ba7-460c-a681-052ba610e740@github.com>
 <xfimJHP5YibKEjbtjTd3iV4ccp5FnRp5J5kYtzyQkMI=.594afae0-8a8a-41bb-b2a5-7eb6b150a691@github.com>
Message-ID: <tVKV2iUvdcWIfkyb_vrlqgvZVLuq2HFNMvitm7Tnaxs=.c9d65255-520d-49bb-a7bb-7e9b2072c3bb@github.com>

On Wed, 17 Sep 2025 23:26:13 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 21 additional commits since the last revision:
>> 
>>  - snapshot 1 test
>>  - Merge remote-tracking branch 'origin/master' into 8367567.expected
>>  - expected
>>  - single exit common
>>  - message
>>  - whitespace
>>  - launcher test
>>  - revert add exports
>>  - decouple logging
>>  - test.javafx.util
>>  - ... and 11 more: https://git.openjdk.org/jfx/compare/7d28830b...98f60999
>
> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ErrorLoggingUtility.java line 36:
> 
>> 34: import com.sun.javafx.logging.PlatformLogger.Level;
>> 35: 
>> 36: public class ErrorLoggingUtility {
> 
> I see you left in the name change to `ErrorLoggingUtility`. I was hoping you'd revert that along with the other changes to this file, since they are now unrelated and make the PR much larger to review. Yes, I know it's a mechanical change, but I find it hard to see what has "really" changed now.
> 
> Suggestion: revert the name change to this utility, since it is no longer relevant.

Further, there are at least some files in javafx.base that are unchanged except for this name change, a reordering of imports, and a copyright year update. See `modules/javafx.base/src/test/java/test/javafx/binding/BindingsArrayTest.java` which has a large number of changes, but I think the whole file would be reverted and untouched (meaning no need for 2025) if you revert the name change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2356997790

From hmeda at openjdk.org  Thu Sep 18 06:05:37 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 18 Sep 2025 06:05:37 GMT
Subject: [jfx25u] RFR: 8366744: Update SQLite to 3.50.4
Message-ID: <Lix4wFlJhi-jrSQhz_-2Eih0DGGGXrmLV_xp1VULdys=.4c5891e8-d14d-49b9-8320-04c3ac6968de@github.com>

Clean Backport

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

Commit messages:
 - Backport 749b5dfbb7387b681155c0769f2c0fe0676d743b

Changes: https://git.openjdk.org/jfx25u/pull/15/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=15&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366744
  Stats: 3843 lines in 4 files changed: 2063 ins; 554 del; 1226 mod
  Patch: https://git.openjdk.org/jfx25u/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/15/head:pull/15

PR: https://git.openjdk.org/jfx25u/pull/15

From jdv at openjdk.org  Thu Sep 18 09:13:00 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 18 Sep 2025 09:13:00 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

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

> 34:  * {@code -Dtest.screenshot=true} command line argument.
> 35:  * <p>
> 36:  * Using Safari, the screenshot {@code data:} URL can be pasted into the address bar

Tested with Safari, Firefox and Chrome. Only Chrome has limitation of length for large data URL's and truncates the image. If the desktop is large/diverse enough even Safari is not able to load the data URL's in my Macbook. May be we should make generic statement and mention Safari worked better for us.

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

> 50: 
> 51:     @Override
> 52:     public void testFailed(ExtensionContext extensionContext, Throwable err) {

If i induce failure in `test.robot.javafx.scene.layout.RegionBackgroundFillUITest.basicFill_Radius4` and run it with `@ExtendWith(ScreenCaptureTestWatcher.class)` annotation on RegionBackgroundFillUITest class. I see that screen capture happens after the test window in closed.

May be in such cases, its better to call `ScreenshotCapture.writeScreenshot()` directly before we throw AssertionError on failure?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1910#discussion_r2358111261
PR Review Comment: https://git.openjdk.org/jfx/pull/1910#discussion_r2358157406

From tsayao at openjdk.org  Thu Sep 18 09:31:37 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 18 Sep 2025 09:31:37 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v61]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <2ThBCybu1xlckZC10paTC7WWtZIBHfSqEa5KLaYRheI=.ebd13bf0-24ca-47cf-a621-c84c3e54abff@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
 - - Fix scene resize when window is unresizable
 - - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view
 - - Fix tests
 - - Fix FOCUS_LOST begin sent on focused windows
 - - Remove CenterOnScreenTest.java
 - Merge branch 'master' into 8354943
 - - Fix (SetSceneScalingTest)
 - - Fix mistake (assertTrue -> assumeTrue)
 - ... and 64 more: https://git.openjdk.org/jfx/compare/c95cdcdc...425d9b01

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=60
  Stats: 4131 lines in 27 files changed: 2732 ins; 770 del; 629 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 aghaisas at openjdk.org  Thu Sep 18 09:31:58 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 18 Sep 2025 09:31:58 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6 [v2]
In-Reply-To: <Cky0Y4FpR-Ga6LyeCzIq_KrdxfCnKu4Qyp87LnyGXIA=.a3378c4d-5881-44c5-b4be-49dd6131f5f2@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
 <Cky0Y4FpR-Ga6LyeCzIq_KrdxfCnKu4Qyp87LnyGXIA=.a3378c4d-5881-44c5-b4be-49dd6131f5f2@github.com>
Message-ID: <iVEdMdQP5JF3IdZ2XwCn6z-LXH0kET7H_Jwv0-PCFhU=.fbb64719-0eaa-49c5-afc5-54ac50e2cb90@github.com>

On Wed, 17 Sep 2025 20:36:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Further additions to the MonkeyTester application:
>> 
>> - readme.md: 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`
>> - TableView page: canvas based cell and row factories
>> - Dialog page
>> - Progress Bar Page
>> - additional scripts in the WritingSystemsDemo
>> - pure Swing JTextField/JTextArea window
>> - ImageView page
>> - AudioClip page
>> - events in Drag and Drop page
>> - added miscellaneous options
>> - TextFlow page: updated hit info visualization, tab stop policy
>> - WebView page: added direct html input
>> 
>> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).
>
> 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 eight additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8353743.monkey
>  - Merge branch 'master' into 8353743.monkey
>  - spelling
>  - jdk jfx 24
>  - whitespace
>  - whitespace
>  - sync up with standalone repo

Marked as reviewed by aghaisas (Reviewer).

Thanks for fixing DialogPane test!
This update looks good to me.

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

PR Review: https://git.openjdk.org/jfx/pull/1887#pullrequestreview-3238432362
PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3306465219

From tsayao at openjdk.org  Thu Sep 18 09:43:33 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 18 Sep 2025 09:43:33 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v62]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <MJojL2NhiBTijtfweAItN5gyZQ71LDmQxDTOWi1SUA0=.a1d993de-207e-49f1-a56b-bf0444b14868@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Fix StageOwnershipTest label + minor adjustments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/425d9b01..36b50681

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=61
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=60-61

  Stats: 25 lines in 1 file changed: 14 ins; 8 del; 3 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  Thu Sep 18 09:48:35 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 18 Sep 2025 09:48:35 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v60]
In-Reply-To: <ZzmOr-_e5bmpN3eIbXihvTtim6iM7YSNKJ1Tp3k823E=.be1a9a1d-6690-439a-b55f-7fcceafdb200@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@github.com>
 <hVHQezNT5ebKI_KV8finuSGLZRmYom-BB0UMIuo3G70=.715cf799-86fb-4c1e-86d1-314ebfd62a9c@github.com>
 <ZzmOr-_e5bmpN3eIbXihvTtim6iM7YSNKJ1Tp3k823E=.be1a9a1d-6690-439a-b55f-7fcceafdb200@github.com>
Message-ID: <DuI9seMSq83mgCx7GtFAqiYd6NW3A5PaLKCWHFuEg3Q=.102f6f94-c0ad-4e8f-ab1d-744948eafae1@github.com>

On Wed, 17 Sep 2025 18:01:47 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > I've been going through the review and tests here, I still have some more code to review but I did notice there are some test failures on Windows:
> 
> I've tracked down one issue with these tests. Some of them try to verify where the top stage is by sampling from a fixed location in screen coordinates, typically calling `getColor(100, 100)`. Depending on the platform and stage style this might sample a pixel from the Label in the middle of the top stage's scene. This happens on Windows when the top stage's style is EXTENDED. This doesn't happen on macOS because the top stage gets shifted down to avoid the menu bar (the test tries to position the top stage at y = 0 but it ends up at y = 25 instead).

Moved the label to the bottom right. Another cause of this "shifting" behavior are desktop panels.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3306536408

From tsayao at openjdk.org  Thu Sep 18 09:48:37 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 18 Sep 2025 09:48:37 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <RVjZWy1rbrXezApqjkzMxtlYEYwd4aroHg9hPCy0WMU=.1f3a3292-b9cb-426a-924f-17ac94659c26@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
 <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
 <iKTVR5zKzaC6vGk7b4uQDSEd4ns23_UIqClvY6oGlU8=.1dce0a9c-0a12-46ff-9845-f820d2f438a3@github.com>
 <RVjZWy1rbrXezApqjkzMxtlYEYwd4aroHg9hPCy0WMU=.1f3a3292-b9cb-426a-924f-17ac94659c26@github.com>
Message-ID: <FJ8RDaaHx52f3w3NtOL8vStIxDuy7h2P4LZWG1D1HKc=.f021d992-e9b8-4327-b1ea-a3392f2fe2da@github.com>

On Fri, 22 Aug 2025 21:05:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> I think you use assumeTrue to check whether the test should proceed. So you want `assumeTrue(!PlatformUtil.isWindows())` or `assumeFalse(PlatformUtil.isWindows())`.
>
> I always get confused by this. Will fix it.

Fixed

>> Since it picks up a random color it could get a match by accident. Highly unlikely but possible. Though I see what you're saying, any time we use a robot to sample a pixel we could get the expected color by chance because it just happens to be in the desktop image.
>
> Good point, I'll fix it.

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2358255540
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2358259237

From tsayao at openjdk.org  Thu Sep 18 09:48:36 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 18 Sep 2025 09:48:36 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <dAvsKup6N3xp1zC1y63iA8muMb7w3ztN0ZV7vzj7lto=.a40be46a-a870-423e-b3d2-c2fec9b6201c@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
 <A6SLVZQERnvvpivyWGTcC6tp0hUFTLr6LXvWN3uXIdI=.f15271a1-dff3-4a76-8d19-68412bc2638c@github.com>
 <dAvsKup6N3xp1zC1y63iA8muMb7w3ztN0ZV7vzj7lto=.a40be46a-a870-423e-b3d2-c2fec9b6201c@github.com>
Message-ID: <1x-CMgyaPiCgxiCd2j8R1bBIifEPocTqAsaciHUHzIU=.ddea4b36-7b65-4b2f-bfdc-b655f55f87fb@github.com>

On Fri, 22 Aug 2025 21:32:12 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The test still looks incorrect. You're passing in posX and posY as the tolerance deltas.
>> 
>> I'm not sure what you're testing here. There's an internal algorithm that sets the window's x and y coordinate to center it. You're replicating that algorithm here and testing whether the window has the same x and y values. If you're concerned that the platform code didn't actually move the window you would need to use a robot to sample a pixel and verify that the window is where you expect. Or was there some other centering problem you saw on Linux?
>
> On Linux, when frame extents are received (and it might arrive later depending on the compositor / window manager), it must do a correction on the centering accounting the decorations (glass_window.cpp around line 895).  This was the idea behind the test, but I think I  "over tested" and this is really not useful. Will remove it.

Test removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2358256386

From aghaisas at openjdk.org  Thu Sep 18 11:21:09 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 18 Sep 2025 11:21:09 GMT
Subject: RFR: 8271205: [windows] Intermittent test failure in
 test.javafx.scene.web.MiscellaneousTest::testDOMTimer
In-Reply-To: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
References: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
Message-ID: <m06jUUiL_l9cQ47pXFI6tWcB6EdOPYVvcbCLJHTtPn4=.db00f68c-f0b5-48f2-9de6-4b6c72e7b3b0@github.com>

On Wed, 17 Sep 2025 02:40:43 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer
> Analysis:
> setTimeout call is not a real-time function. it is considered just a minimum delay before the callback is executed. The actual time taken depends
> 
> How long it takes to process any messages ahead of the already task in the queue?
> Current load on the CPU.
> The number of tasks being executed by the JS engine.
> current state of OS/Browser.
> However, we have to set a minimum timeout value of at least 10 ms, as recommended by Webkit/w3c. Setting value of 1o ms might prevent some un-defined behavior.

modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 193:

> 191:             for (int i = 0; i < timer.INTERVAL_COUNT; i++) {
> 192:                 int timeout = i * (1000 / timer.INTERVAL_COUNT);
> 193:                 // Webkit recomends minimum timeout value should be 10

Please correct the typo : recomends --> recommends

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1907#discussion_r2358670865

From kcr at openjdk.org  Thu Sep 18 12:19:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 12:19:39 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>
Message-ID: <PLGDPtReLKWT1TlJ1YeTkq_ph5FpTgrb9hj-PYw5y7g=.4e096f65-c930-4c19-a85e-3c0882448acc@github.com>

On Thu, 18 Sep 2025 09:08:33 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
>> 
>> Added corresponding gradle option `TEST_SCREENSHOT`.
>> 
>> The function is disabled by default for privacy reasons.
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 52:
> 
>> 50: 
>> 51:     @Override
>> 52:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
> 
> If i induce failure in `test.robot.javafx.scene.layout.RegionBackgroundFillUITest.basicFill_Radius4` and run it with `@ExtendWith(ScreenCaptureTestWatcher.class)` annotation on RegionBackgroundFillUITest class. I see that screen capture happens after the test window in closed.
> 
> May be in such cases, its better to call `ScreenshotCapture.writeScreenshot()` directly before we throw AssertionError on failure?

That would be one option; if we do this, we would need to move the property check to `writeScreenshot` (or provide a utility method for that purpose).

Another option would be to modify the tests to which you plan to add `ScreenshotCapture` to not hide the stage in their `@AfterEach` method (perhaps moving it to `@BeforeEach` instead).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1910#discussion_r2358934095

From bdunkley-smith at bigpond.com  Thu Sep 18 12:22:51 2025
From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith)
Date: Thu, 18 Sep 2025 22:22:51 +1000
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
In-Reply-To: <DM3PPFC82B87818ECC8A922B85853C766CA9917A@DM3PPFC82B87818.namprd10.prod.outlook.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
 <DM3PPFC82B87818ECC8A922B85853C766CA9917A@DM3PPFC82B87818.namprd10.prod.outlook.com>
Message-ID: <002501dc2896$f43c9a10$dcb5ce30$@bigpond.com>

Thank you for your feedback Alexander.

 

>From what I can see there doesn?t seem to have been any, but do you know if there has been any progress towards a resolution of JDK-8305842 and if not, what would trigger activity on that?

 

I?m surprised JDK-8305842 has remained unresolved because I assume many others must have encountered this bug. I have certainly had ?conversations? with others (https://www.b4x.com/android/forum/threads/javafx-mediaview-under-win11.166839/ & https://www.b4x.com/android/forum/threads/jmediaview.166994/) who have also encountered it. In my case since updating from Win10 to Win 11 earlier this year, I have had to abandon using the feature in my basketball stats display application which shows a sequence of short videos because of the random/intermittent/flaky nature of the symptom and reverted to use of a separate application (vMix) to do this, which is disappointing/inconvenient.

 

Incidentally, thank you to this community which I find very welcoming and supportive, especially for someone like me who is somewhat out of their depth.

 

Thanks,

 

Bryon

 

From: Alexander Matveev <alexander.matveev at oracle.com> 
Sent: Thursday, 18 September 2025 6:36 AM
To: Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>; openjfx-dev at openjdk.org
Subject: Re: Availability of JavaFX build incorporating JDK-8366217 fix

 

Hi Bryon,

 

No, JDK-8366217 does not resolve JDK-8305842. JDK-8305842 is still reproducible on Windows 11 with JDK-8366217.

 

Thanks,

Alexander

 

From: openjfx-dev < <mailto:openjfx-dev-retn at openjdk.org> openjfx-dev-retn at openjdk.org> on behalf of Bryon Dunkley-Smith < <mailto:bdunkley-smith at bigpond.com> bdunkley-smith at bigpond.com>
Date: Tuesday, September 16, 2025 at 6:56?PM
To:  <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org < <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org>
Subject: Availability of JavaFX build incorporating JDK-8366217 fix

Hi All,

 

Apologies in advance if the terminology in my question is incorrect as I?m somewhat out of my depth here.

 

I have been monitoring  <https://bugs.openjdk.org/browse/JDK-8305842> https://bugs.openjdk.org/browse/JDK-8305842 (Video sometimes does not start when reinitializing in Windows 11) for progress with interest because I have a legacy JavaFX based application which has functioned flawlessly for several years, but since upgrading from Win10 to Win1, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media? with success previously and it often runs without error. 

 

So when I saw  <https://bugs.openjdk.org/browse/JDK-8366217> https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my issue of intermittent/random failures of videos.

 

I see that ?This pull request has now been integrated.? and being ignorant of how this finds its way into a release of JavaFX, could someone advise me of how I would know if a version (early release?) is available incorporating this ?fix? and where I can download it from.

 

Thanks,

 

Bryon

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

From jdv at openjdk.org  Thu Sep 18 13:50:02 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 18 Sep 2025 13:50:02 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <PLGDPtReLKWT1TlJ1YeTkq_ph5FpTgrb9hj-PYw5y7g=.4e096f65-c930-4c19-a85e-3c0882448acc@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>
 <PLGDPtReLKWT1TlJ1YeTkq_ph5FpTgrb9hj-PYw5y7g=.4e096f65-c930-4c19-a85e-3c0882448acc@github.com>
Message-ID: <2RGPVfrifq0FB0JBAAngJZdngHLOsSMgVgaeH-pqFV8=.abcf2720-d623-4411-8598-5e1928756a69@github.com>

On Thu, 18 Sep 2025 12:17:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 52:
>> 
>>> 50: 
>>> 51:     @Override
>>> 52:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>> 
>> If i induce failure in `test.robot.javafx.scene.layout.RegionBackgroundFillUITest.basicFill_Radius4` and run it with `@ExtendWith(ScreenCaptureTestWatcher.class)` annotation on RegionBackgroundFillUITest class. I see that screen capture happens after the test window in closed.
>> 
>> May be in such cases, its better to call `ScreenshotCapture.writeScreenshot()` directly before we throw AssertionError on failure?
>
> That would be one option; if we do this, we would need to move the property check to `writeScreenshot` (or provide a utility method for that purpose).
> 
> Another option would be to modify the tests to which you plan to add `ScreenshotCapture` to not hide the stage in their `@AfterEach` method (perhaps moving it to `@BeforeEach` instead).

Thanks for the suggestion. Second option seems better, with some refactoring moving stage closing logic to `@BeforeEach` method works and it takes proper screen capture of test window also.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1910#discussion_r2359405174

From jdv at openjdk.org  Thu Sep 18 14:00:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 18 Sep 2025 14:00:41 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <tchBuPFmtYVUtuH6L4j-n7ucJERB455vsGw_fKLTxWM=.5715e610-c6fe-4ca9-9f53-cd6f5706015d@github.com>
Message-ID: <0lDb504iu5rVc7lHRD5k0lc-MknXBqp1RYRtHCvRbWc=.4a725e0d-07ff-4c6e-9319-a1e4cda99949@github.com>

On Thu, 18 Sep 2025 08:50:44 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
>> 
>> Added corresponding gradle option `TEST_SCREENSHOT`.
>> 
>> The function is disabled by default for privacy reasons.
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 36:
> 
>> 34:  * {@code -Dtest.screenshot=true} command line argument.
>> 35:  * <p>
>> 36:  * Using Safari, the screenshot {@code data:} URL can be pasted into the address bar
> 
> Tested with Safari, Firefox and Chrome. Only Chrome has limitation of length for large data URL's and truncates the image. If the desktop is large/diverse enough even Safari is not able to load the data URL's in my Macbook. May be we should make generic statement and mention Safari worked better for us.

I don't have objection to mentioning "Safari" only, since it is already mentioned in the same file before.
But i feel the statement can be improved to include firefox also, then we are not limited to specific platform.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1910#discussion_r2359454719

From jdv at openjdk.org  Thu Sep 18 14:00:38 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 18 Sep 2025 14:00:38 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <Y05a_rzcRCtI1Y-qEGVmsHDDZCSCfov8ryD2bUQKhmI=.923a205d-e153-45a4-9e09-2bfd784d0528@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1910#pullrequestreview-3239932933

From angorya at openjdk.org  Thu Sep 18 14:32:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 14:32:24 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher [v2]
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

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

  firefox

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1910/files
  - new: https://git.openjdk.org/jfx/pull/1910/files/1284a09a..06603eab

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

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

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

From jdv at openjdk.org  Thu Sep 18 14:32:25 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 18 Sep 2025 14:32:25 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher [v2]
In-Reply-To: <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
Message-ID: <ZPMm5uN9zZNlMe_Nhw8b-i94fM5oLOToKPBTVGHz2rA=.39d21c59-694f-4dcc-ad97-18fd38616c75@github.com>

On Thu, 18 Sep 2025 14:28:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
>> 
>> Added corresponding gradle option `TEST_SCREENSHOT`.
>> 
>> The function is disabled by default for privacy reasons.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   firefox

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1910#pullrequestreview-3240117550

From angorya at openjdk.org  Thu Sep 18 14:35:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 14:35:33 GMT
Subject: RFR: 8353743: [TestBug] Monkey Tester Application Update 6 [v2]
In-Reply-To: <Cky0Y4FpR-Ga6LyeCzIq_KrdxfCnKu4Qyp87LnyGXIA=.a3378c4d-5881-44c5-b4be-49dd6131f5f2@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
 <Cky0Y4FpR-Ga6LyeCzIq_KrdxfCnKu4Qyp87LnyGXIA=.a3378c4d-5881-44c5-b4be-49dd6131f5f2@github.com>
Message-ID: <dX_UU74H8saTaUQOwFUw93RlBIu0PcAcv6txjij2Opg=.33dda277-40f8-445b-853a-853c80b05764@github.com>

On Wed, 17 Sep 2025 20:36:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Further additions to the MonkeyTester application:
>> 
>> - readme.md: 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`
>> - TableView page: canvas based cell and row factories
>> - Dialog page
>> - Progress Bar Page
>> - additional scripts in the WritingSystemsDemo
>> - pure Swing JTextField/JTextArea window
>> - ImageView page
>> - AudioClip page
>> - events in Drag and Drop page
>> - added miscellaneous options
>> - TextFlow page: updated hit info visualization, tab stop policy
>> - WebView page: added direct html input
>> 
>> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).
>
> 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 eight additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8353743.monkey
>  - Merge branch 'master' into 8353743.monkey
>  - spelling
>  - jdk jfx 24
>  - whitespace
>  - whitespace
>  - sync up with standalone repo

Thank you all for review and suggestions!

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

PR Comment: https://git.openjdk.org/jfx/pull/1887#issuecomment-3307793993

From angorya at openjdk.org  Thu Sep 18 14:35:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 14:35:36 GMT
Subject: Integrated: 8353743: [TestBug] Monkey Tester Application Update 6
In-Reply-To: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
References: <--vqTQE3VC4RALmL8zADNCva_7bgQv5BexjntEtMmB4=.583797d1-9ff5-4bc0-b147-90be0cd03d65@github.com>
Message-ID: <nph92I8fZOhJUBNKcVcpBdq26jVtKsGxUJiTQV4qdV8=.94bda330-c781-4490-a891-4ee2e5443728@github.com>

On Mon, 8 Sep 2025 19:49:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Further additions to the MonkeyTester application:
> 
> - readme.md: 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`
> - TableView page: canvas based cell and row factories
> - Dialog page
> - Progress Bar Page
> - additional scripts in the WritingSystemsDemo
> - pure Swing JTextField/JTextArea window
> - ImageView page
> - AudioClip page
> - events in Drag and Drop page
> - added miscellaneous options
> - TextFlow page: updated hit info visualization, tab stop policy
> - WebView page: added direct html input
> 
> Also, upgraded the build scripts and eclipse settings to **JDK24** and **JFX24** (you may need to upgrade Eclipse).

This pull request has now been integrated.

Changeset: bcc86b81
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bcc86b81e2a1ac246889b226c026bf6f02f517ff
Stats:     1928 lines in 45 files changed: 1509 ins; 140 del; 279 mod

8353743: [TestBug] Monkey Tester Application Update 6

Reviewed-by: aghaisas

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

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

From kcr at openjdk.org  Thu Sep 18 14:54:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 14:54:01 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher [v2]
In-Reply-To: <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
Message-ID: <sR1q2k5vgrv5DTBQQykmhLAvzlTZnsCdRvxcaHMrSS4=.29c551a4-6521-47f6-817e-ba5f48d52ee1@github.com>

On Thu, 18 Sep 2025 14:32:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
>> 
>> Added corresponding gradle option `TEST_SCREENSHOT`.
>> 
>> The function is disabled by default for privacy reasons.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   firefox

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1910#pullrequestreview-3240257331

From kcr at openjdk.org  Thu Sep 18 14:57:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 14:57:20 GMT
Subject: RFR: 8271205: [windows] Intermittent test failure in
 test.javafx.scene.web.MiscellaneousTest::testDOMTimer
In-Reply-To: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
References: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
Message-ID: <S-pZXZnoG0ILGS7sYpUaN42irKcnGA-3MwPjFmeTnho=.45c67345-6da4-42af-8a35-90137d229ddf@github.com>

On Wed, 17 Sep 2025 02:40:43 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer
> Analysis:
> setTimeout call is not a real-time function. it is considered just a minimum delay before the callback is executed. The actual time taken depends
> 
> How long it takes to process any messages ahead of the already task in the queue?
> Current load on the CPU.
> The number of tasks being executed by the JS engine.
> current state of OS/Browser.
> However, we have to set a minimum timeout value of at least 10 ms, as recommended by Webkit/w3c. Setting value of 1o ms might prevent some un-defined behavior.

LGTM. I'll reapprove once you fix the typo in the comment.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1907#pullrequestreview-3240275461

From angorya at openjdk.org  Thu Sep 18 15:09:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 15:09:47 GMT
Subject: RFR: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher [v2]
In-Reply-To: <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
 <gY-FbokIkM5kXBOOU9IydlGG4RtSg8pMxTS355yG2RY=.ac2cc1e2-63f7-4c16-b8fe-7f8fa98cdc19@github.com>
Message-ID: <NxKTtjJB3NNHhSaOzcxWLkj8laUSbNhvSozFrxfp1yQ=.9e2b7c4e-2ec4-4e75-bc31-d76400a80a2d@github.com>

On Thu, 18 Sep 2025 14:32:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
>> 
>> Added corresponding gradle option `TEST_SCREENSHOT`.
>> 
>> The function is disabled by default for privacy reasons.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   firefox

thank you all

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

PR Comment: https://git.openjdk.org/jfx/pull/1910#issuecomment-3308001070

From angorya at openjdk.org  Thu Sep 18 15:09:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 15:09:48 GMT
Subject: Integrated: 8367915: [TestBug] Add system property to
 ScreenCaptureTestWatcher
In-Reply-To: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
References: <5HCpgTt8HQxHPHlfGcLxar5463exQC4vWc2q2-w4S_U=.cf9500e8-8ba2-4f87-8bc5-4cbc724c8cde@github.com>
Message-ID: <ii-oVD9-ywAOedjwBgRhj33Uf1T56Yhb5reCCyIEo34=.ce80429a-9636-4316-97b2-1a277ae5fb0a@github.com>

On Wed, 17 Sep 2025 18:07:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Added `test.screenshot` system property to the `ScreenCaptureTestWatcher` to control writing of the screenshot data url to stderr.
> 
> Added corresponding gradle option `TEST_SCREENSHOT`.
> 
> The function is disabled by default for privacy reasons.

This pull request has now been integrated.

Changeset: 772d1c64
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/772d1c64f9d591fd0d038442faf63c538bd5960c
Stats:     21 lines in 2 files changed: 18 ins; 0 del; 3 mod

8367915: [TestBug] Add system property to ScreenCaptureTestWatcher

Reviewed-by: kcr, jdv

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

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

From angorya at openjdk.org  Thu Sep 18 15:19:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 15:19:23 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v6]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <dldQRdttKo1bE9uMBBnjeL0jZoJgVkhDjSlWF1IAcSQ=.3fdaa9df-2076-4329-9b70-d93a004d4138@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> - fixed ErrorLoggingUtiltity name

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

  reverted renaming

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/98f60999..4954914f

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

  Stats: 720 lines in 13 files changed: 71 ins; 71 del; 578 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Thu Sep 18 15:19:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 15:19:25 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v5]
In-Reply-To: <tVKV2iUvdcWIfkyb_vrlqgvZVLuq2HFNMvitm7Tnaxs=.c9d65255-520d-49bb-a7bb-7e9b2072c3bb@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <4ZEScKI8ZncLDY3W5PTlLjVNV-uYsXRbzSqqM_GhPRM=.b4a5db0b-6ba7-460c-a681-052ba610e740@github.com>
 <xfimJHP5YibKEjbtjTd3iV4ccp5FnRp5J5kYtzyQkMI=.594afae0-8a8a-41bb-b2a5-7eb6b150a691@github.com>
 <tVKV2iUvdcWIfkyb_vrlqgvZVLuq2HFNMvitm7Tnaxs=.c9d65255-520d-49bb-a7bb-7e9b2072c3bb@github.com>
Message-ID: <InPrpwQu0Vk7BrH5IDET7DwN6T3JqpQfNYAkCgT0EpI=.a9c8a545-6c2e-433a-a56f-755a36e6358c@github.com>

On Wed, 17 Sep 2025 23:32:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ErrorLoggingUtility.java line 36:
>> 
>>> 34: import com.sun.javafx.logging.PlatformLogger.Level;
>>> 35: 
>>> 36: public class ErrorLoggingUtility {
>> 
>> I see you left in the name change to `ErrorLoggingUtility`. I was hoping you'd revert that along with the other changes to this file, since they are now unrelated and make the PR much larger to review. Yes, I know it's a mechanical change, but I find it hard to see what has "really" changed now.
>> 
>> Suggestion: revert the name change to this utility, since it is no longer relevant.
>
> Further, there are at least some files in javafx.base that are unchanged except for this name change, a reordering of imports, and a copyright year update. See `modules/javafx.base/src/test/java/test/javafx/binding/BindingsArrayTest.java` which has a large number of changes, but I think the whole file would be reverted and untouched (meaning no need for 2025) if you revert the name change.

yikes.  to be be renamed in JDK-8367995

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359838226

From angorya at openjdk.org  Thu Sep 18 15:26:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 15:26:27 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> - fixed ErrorLoggingUtiltity name

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

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/4954914f..447b96de

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

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

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

From mfox at openjdk.org  Thu Sep 18 15:50:11 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 18 Sep 2025 15:50:11 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
References: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
Message-ID: <rJTP0x--Nsn5Vyou250vumOnCAbCzK1TwGy8BTxC_Po=.7a3ce93e-5ce8-43cf-9a3e-2bb2f0ffef44@github.com>

On Wed, 16 Jul 2025 08:50:31 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> This PR fixes `isFocused()` returning invalid value when Stage fails to receive focus after calling `Stage.show()`. This problem is Windows-only.
> 
> In Windows the `SetForegroundWindow()` API lists [a set of conditions to successfully grant focus to a Window](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow#remarks). If any of the conditions are not met, the API will return FALSE. JavaFX did not respect that and instead assumed that receiving `WM_ACTIVATE` with our Window being activated is enough to assume the Window is in focus (which in some cases is not true).
> 
> I first tried reacting to `WM_SETFOCUS` and `WM_KILLFOCUS` but it seems those messages are not sent when the window is shown for the first time (instead `WM_ACTIVATE` is used).
> 
> To correct this behavior, I noticed the following path is the most reliable:
> - Call `ShowWindow()` using `SW_SHOWNA` instead of `SW_SHOW` - that makes the window visible but does NOT activate it
> - Call `SetForegroundWindow()` - that will attempt to give the Window focus and will also activate it if it is successful
>   - If successful, Java `notifyFocus` callback will be called via `WM_ACTIVATE` handler
>   - If it fails, we call the `notifyFocus` callback manually informing the upper layers the focus is lost. This establishes the correct state of `Window.focused` property.
> 
> With this change I observed that all tests pass as intended as long as two conditions are met (these are needed to satisfy `SetForegroundWindow()` restrictions):
> - Gradle build is ran without the Gradle daemon
> - The terminal running Gradle test is in foreground
> 
> If any of above two conditions is not met, some tests (including canary test from https://github.com/openjdk/jfx/pull/1804) now timeout/fail when checking whether `Window.isFocused()` is true.
> 
> Manually started JavaFX apps (ex. Ensemble) run as they used to and still receive focus upon Stage showing.

I?ve been testing this PR by launching the manual KeyboardTest app.

	java @build/run.args tests/manual/events/KeyboardTest.java

The call to SetForegroundWindow fails but not before activating the window. Since it?s not the foreground window this PR correctly sets the JavaFX focused property back to false. But when I later click on the title bar to bring the window to the foreground the focused property is not updated.

I?m not sure how we?re expected to detect that our HWND has come to the foreground. There?s no specific message sent when this happens and since the OS thinks the window is already active and focused we don?t get WM_ACTIVATE or WM_SETFOCUS. There?s some messages we could use heuristically (like WM_NCACTIVATE) but I couldn?t find anything more clear cut. I'll keep looking but it doesn't look like Windows makes this easy.

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3308226998

From kcr at openjdk.org  Thu Sep 18 16:09:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 16:09:27 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
Message-ID: <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>

On Thu, 18 Sep 2025 15:26:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

Thanks for reverting the renaming. It's much easier to review now.

I left a few inline comments. I'll test it and then also finish my review. The regex is a bit of a head scratcher (as they always are), so I'll probably just do a quick "eh, looks OK as long as it works" :)

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

> 71:     public void beforeEach() {
> 72:         OutputRedirect.suppressStderr();
> 73:         ErrorLoggingUtiltity.reset();

Same comment as in earlier class: it seems best to leave the reset in a `@BeforeAll` method, unless there is a compelling reason to change it.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 73:

> 71: 
> 72:     /// Returns the captured output, if any, or `null`.
> 73:     /// @return the captured output string, or `null`

The empty string might be a better choice if there is no output.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 103:

> 101:             Map<String, Integer> exp = toMap(expected);
> 102:             if (!errors.equals(exp)) {
> 103:                 stderr.println("Mismatch in thrown exceptions:\n  expected=" + exp + "\n  observed=" + errors);

This should cause the test to fail. Set `err = true` here.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 141:

> 139: 
> 140:     private static Map<String, Integer> toMap(Object... expected) {
> 141:         HashMap<String, Integer> m = new HashMap<>();

Suggestion: Given how they are used, you might consider using a `Set` (which could be created as either a `LinkedHashSet` or `TreeSet`) instead. This would simplify the logic a bit.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 153:

> 151:                     }
> 152:                 } else {
> 153:                     throw new IllegalArgumentException("must specify either Class<? extends Throwable>: " + c);

Typo: remove the "either" since there isn't another one in this case.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 221:

> 219:     }
> 220: 
> 221:     // should I leave this test here?  to test the test?

Seems reasonable.

tests/system/src/test/java/test/com/sun/javafx/application/SingleExitCommon.java line 141:

> 139:             boolean appShouldExit) {
> 140: 
> 141:         doTestCommon(implicitExit, reEnableImplicitExit, stageShown, ThrowableType.NONE, appShouldExit);

Minor: This is an unrelated formatting change in a method that is otherwise untouched.

tests/system/src/test/java/test/launchertest/ModuleLauncherTest.java line 60:

> 58:     private final int testExitCode = ERROR_NONE;
> 59: 
> 60:     private void doTestLaunchModule(String appModulePath, String testAppName, Object ... expected) throws Exception {

No caller of this method passes anything for the newly added `Object ... expected` varargs parameter. I recommend reverting the addition of the parameter.

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3240454716
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359883325
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359889900
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359910671
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359994625
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359928622
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359960040
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360026251
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360048846

From kcr at openjdk.org  Thu Sep 18 16:09:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 16:09:29 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v6]
In-Reply-To: <dldQRdttKo1bE9uMBBnjeL0jZoJgVkhDjSlWF1IAcSQ=.3fdaa9df-2076-4329-9b70-d93a004d4138@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <dldQRdttKo1bE9uMBBnjeL0jZoJgVkhDjSlWF1IAcSQ=.3fdaa9df-2076-4329-9b70-d93a004d4138@github.com>
Message-ID: <RpHh4-y0v_Pkcqbr_D5Tjmq-KX_zHBqnW210hW2r-hE=.f641fa8a-05d0-4d2d-aeb7-a89f3338d314@github.com>

On Thu, 18 Sep 2025 15:19:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted renaming

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 111:

> 109:     public void setUp() throws Exception {
> 110:         OutputRedirect.suppressStderr();
> 111:         ErrorLoggingUtiltity.reset();

Moving the call to `reset` to a `@BeforeEach` method is an unrelated change. It seems safer to restore the `@BeforeAll` method with just the call to reset.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2359868514

From angorya at openjdk.org  Thu Sep 18 16:12:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 16:12:29 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
Message-ID: <TvnMqAELnbrxug297RCilB0aKJfVsI8uCY4oEHUR_Cw=.eb1fcb11-19b5-4f29-a1d1-b4191681ae6c@github.com>

On Thu, 18 Sep 2025 15:26:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

regex: I can try commenting what each part means

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3308340639

From angorya at openjdk.org  Thu Sep 18 16:25:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 16:25:43 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
 <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
Message-ID: <TG6HHrt3NUvx5g2netEd5czqjWvmj3CLXx70VvmewHI=.ec56288b-9b5f-4ce7-94af-5dd2a02ac2de@github.com>

On Thu, 18 Sep 2025 15:25:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 73:
> 
>> 71: 
>> 72:     /// Returns the captured output, if any, or `null`.
>> 73:     /// @return the captured output string, or `null`
> 
> The empty string might be a better choice if there is no output.

this method is not used anymore, will remove.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360157411

From angorya at openjdk.org  Thu Sep 18 16:29:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 16:29:45 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
 <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
Message-ID: <KUg8LZhcEUSr4R8Ymve7sZy0d9mD-aXjzajOJ0PiCao=.d4b91d06-04da-442e-9f0d-8d28a050ce84@github.com>

On Thu, 18 Sep 2025 15:47:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 141:
> 
>> 139: 
>> 140:     private static Map<String, Integer> toMap(Object... expected) {
>> 141:         HashMap<String, Integer> m = new HashMap<>();
> 
> Suggestion: Given how they are used, you might consider using a `Set` (which could be created as either a `LinkedHashSet` or `TreeSet`) instead. This would simplify the logic a bit.

No, I need the counts.
JDK has neither `MultiMap`s nor counting sets.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360175846

From angorya at openjdk.org  Thu Sep 18 16:33:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 16:33:45 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v8]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <pGPkIAi-_G9yCiSqyth63kTbFgZVzHuhHtNVseZ68tw=.15462ee9-c661-4d5d-a7e6-4d7dfe717cc4@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/447b96de..3afa2703

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=06-07

  Stats: 41 lines in 5 files changed: 21 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Thu Sep 18 17:38:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 17:38:15 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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

  static

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/3afa2703..43993624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=07-08

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

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

From hmeda at openjdk.org  Thu Sep 18 17:41:26 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 18 Sep 2025 17:41:26 GMT
Subject: [jfx25u] Integrated: 8366744: Update SQLite to 3.50.4
In-Reply-To: <Lix4wFlJhi-jrSQhz_-2Eih0DGGGXrmLV_xp1VULdys=.4c5891e8-d14d-49b9-8320-04c3ac6968de@github.com>
References: <Lix4wFlJhi-jrSQhz_-2Eih0DGGGXrmLV_xp1VULdys=.4c5891e8-d14d-49b9-8320-04c3ac6968de@github.com>
Message-ID: <3okL3KL4kmMx9ixAXeYvZiX32aBXHkpE6z9t8ujKIC0=.cca56df5-f71f-4b3c-8536-afc798612edc@github.com>

On Thu, 18 Sep 2025 05:57:10 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 104c10b4
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/104c10b473d72d95c57ecb3d72604d5fe20813f4
Stats:     3843 lines in 4 files changed: 2063 ins; 554 del; 1226 mod

8366744: Update SQLite to 3.50.4

Backport-of: 749b5dfbb7387b681155c0769f2c0fe0676d743b

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

PR: https://git.openjdk.org/jfx25u/pull/15

From kcr at openjdk.org  Thu Sep 18 17:54:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 17:54:40 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
Message-ID: <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>

On Thu, 18 Sep 2025 17:38:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static

Last batch of comments. Initial testing looks good.

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 110:

> 108: 
> 109:     @BeforeAll
> 110:     public static void setUpClass() throws Exception {

Minor: this method previously didn't have `throws Exception` and probably doesn't need it.

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 161:

> 159:             map((s) -> findException(s)).
> 160:             forEach((c) -> {
> 161:                 if (c != null) {

Minor suggestion: filter for non-null Strings before the `forEach` rather than checking for non-null in the `forEach` ?

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 181:

> 179:     /// `java.lang.NullPointerException: ...`
> 180:     private static final Pattern EXCEPTION_PATTERN = Pattern.compile(
> 181:         "(?:" +

Looks reasonable to me. :)

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3241127480
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360492978
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360506569
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360514331

From kcr at openjdk.org  Thu Sep 18 17:54:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 17:54:42 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <KUg8LZhcEUSr4R8Ymve7sZy0d9mD-aXjzajOJ0PiCao=.d4b91d06-04da-442e-9f0d-8d28a050ce84@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
 <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
 <KUg8LZhcEUSr4R8Ymve7sZy0d9mD-aXjzajOJ0PiCao=.d4b91d06-04da-442e-9f0d-8d28a050ce84@github.com>
Message-ID: <I0k9WoYlx0hpKKsNUtznM4W9vI9L50SjvKQK-IIpCXM=.d3fcd849-c2a9-4922-96f8-ca75dd04a430@github.com>

On Thu, 18 Sep 2025 16:27:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 141:
>> 
>>> 139: 
>>> 140:     private static Map<String, Integer> toMap(Object... expected) {
>>> 141:         HashMap<String, Integer> m = new HashMap<>();
>> 
>> Suggestion: Given how they are used, you might consider using a `Set` (which could be created as either a `LinkedHashSet` or `TreeSet`) instead. This would simplify the logic a bit.
>
> No, I need the counts.
> JDK has neither `MultiMap`s nor counting sets.

Oh, nm. I missed that the value is a count of that particular exception class.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360430587

From kcr at openjdk.org  Thu Sep 18 17:54:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 17:54:44 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v8]
In-Reply-To: <pGPkIAi-_G9yCiSqyth63kTbFgZVzHuhHtNVseZ68tw=.15462ee9-c661-4d5d-a7e6-4d7dfe717cc4@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <pGPkIAi-_G9yCiSqyth63kTbFgZVzHuhHtNVseZ68tw=.15462ee9-c661-4d5d-a7e6-4d7dfe717cc4@github.com>
Message-ID: <gf9qIgkqwBpA-YCVrXePEcPDUgtrswd4mFoWlILDrjQ=.f2075a48-cafa-4f4a-ab52-c8fa10efc80e@github.com>

On Thu, 18 Sep 2025 16:33:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 146:

> 144:                     throw new IllegalArgumentException("must specify Class<? extends Throwable>: " + c);
> 145:                 }
> 146:             } else if(x instanceof String) {

Minor: space after `if`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360435742

From kcr at openjdk.org  Thu Sep 18 17:54:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 17:54:47 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v7]
In-Reply-To: <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <ejpmpNCSk94EiP9voOTXtrEtnElw0UkoBHxqsVXy9cQ=.ffdb625d-3842-4241-8259-3467757b7e5c@github.com>
 <oaN8kDXU6okFbfSz6PfGo1uC3afF85s3FoEvlXPa9IE=.264c23ee-2d32-4123-a3c6-0a06246323d3@github.com>
Message-ID: <UP69VEKjtgt2EaU5JbLyLYK2nC7N1H3gZWq6odEiI-w=.81f05825-cceb-4b25-a998-621d69742685@github.com>

On Thu, 18 Sep 2025 15:40:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 221:
> 
>> 219:     }
>> 220: 
>> 221:     // should I leave this test here?  to test the test?
> 
> Seems reasonable.

Although, I would remove or reword the comment asking whether you should leave it if you've decided to do so.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360496902

From angorya at openjdk.org  Thu Sep 18 18:04:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 18:04:25 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
Message-ID: <XnBG4j02yeg6rwAZmTBryoSlIxI-neipuYnGn_L3C4c=.816dbd84-536a-4f22-affd-1df314c94f25@github.com>

On Thu, 18 Sep 2025 17:48:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   static
>
> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 161:
> 
>> 159:             map((s) -> findException(s)).
>> 160:             forEach((c) -> {
>> 161:                 if (c != null) {
> 
> Minor suggestion: filter for non-null Strings before the `forEach` rather than checking for non-null in the `forEach` ?

my version is _more efficient_ :-)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360552981

From angorya at openjdk.org  Thu Sep 18 18:04:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 18:04:22 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v10]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <844swWi8gFXSJqYoRIxbYFVKZ5eehNhR2SFNxv3v_ts=.128fb325-c58f-4234-9333-3a0d7676d13e@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/43993624..3ed81350

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=08-09

  Stats: 13 lines in 2 files changed: 1 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From kcr at openjdk.org  Thu Sep 18 18:15:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 18:15:14 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <XnBG4j02yeg6rwAZmTBryoSlIxI-neipuYnGn_L3C4c=.816dbd84-536a-4f22-affd-1df314c94f25@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
 <XnBG4j02yeg6rwAZmTBryoSlIxI-neipuYnGn_L3C4c=.816dbd84-536a-4f22-affd-1df314c94f25@github.com>
Message-ID: <9QhAWAgIVkTEAql7hRzUe5_9ayK2V7GaAtzll9eK830=.853ec48d-28fc-411c-ac25-36a472adc2df@github.com>

On Thu, 18 Sep 2025 18:00:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/test/javafx/util/OutputRedirect.java line 161:
>> 
>>> 159:             map((s) -> findException(s)).
>>> 160:             forEach((c) -> {
>>> 161:                 if (c != null) {
>> 
>> Minor suggestion: filter for non-null Strings before the `forEach` rather than checking for non-null in the `forEach` ?
>
> my version is _more efficient_ :-)

I doubt it. Anyway, it doesn't really matter all that much.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360594144

From angorya at openjdk.org  Thu Sep 18 18:42:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 18:42:52 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <9QhAWAgIVkTEAql7hRzUe5_9ayK2V7GaAtzll9eK830=.853ec48d-28fc-411c-ac25-36a472adc2df@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
 <XnBG4j02yeg6rwAZmTBryoSlIxI-neipuYnGn_L3C4c=.816dbd84-536a-4f22-affd-1df314c94f25@github.com>
 <9QhAWAgIVkTEAql7hRzUe5_9ayK2V7GaAtzll9eK830=.853ec48d-28fc-411c-ac25-36a472adc2df@github.com>
Message-ID: <yz7kbbPpn7wmMdlT11PoEF4lzN_9LjoSrwRGu0-cp7g=.6f3895c5-cb0c-4796-b4a4-ef6feb544bd5@github.com>

On Thu, 18 Sep 2025 18:12:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> my version is _more efficient_ :-)
>
> I doubt it. Anyway, it doesn't really matter all that much.

off topic, but it is more efficient - check out

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/MoreEfficient.java

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360677550

From kcr at openjdk.org  Thu Sep 18 18:42:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 18:42:54 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v10]
In-Reply-To: <844swWi8gFXSJqYoRIxbYFVKZ5eehNhR2SFNxv3v_ts=.128fb325-c58f-4234-9333-3a0d7676d13e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <844swWi8gFXSJqYoRIxbYFVKZ5eehNhR2SFNxv3v_ts=.128fb325-c58f-4234-9333-3a0d7676d13e@github.com>
Message-ID: <SpPCcWvI8Yj3W1nWBsXPXVe4lGWQ9xezsKpjreZdP_U=.7d43d6bb-77c9-451e-8321-646711f4ed8a@github.com>

On Thu, 18 Sep 2025 18:04:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 244:

> 242:             } finally {
> 243:                 OutputRedirect.checkAndRestoreStderr(ClassCastException.class);
> 244:             }

This fails for me, which is not surprising since the snapshot is asynchronous. You probably want to move everything (the suppressStderr and the try/finally with the checkAndRestoreStderr) out of the runAndWait, but even that might not be sufficient without a delay after `latch.getCount()`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360686619

From angorya at openjdk.org  Thu Sep 18 18:42:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 18:42:55 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v10]
In-Reply-To: <SpPCcWvI8Yj3W1nWBsXPXVe4lGWQ9xezsKpjreZdP_U=.7d43d6bb-77c9-451e-8321-646711f4ed8a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <844swWi8gFXSJqYoRIxbYFVKZ5eehNhR2SFNxv3v_ts=.128fb325-c58f-4234-9333-3a0d7676d13e@github.com>
 <SpPCcWvI8Yj3W1nWBsXPXVe4lGWQ9xezsKpjreZdP_U=.7d43d6bb-77c9-451e-8321-646711f4ed8a@github.com>
Message-ID: <pHT1AKYHdahU1b4COKjLGjoP8KeVkOKEk-DfyCfZkGg=.975916e8-534b-4071-9799-5678843219dd@github.com>

On Thu, 18 Sep 2025 18:38:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 244:
> 
>> 242:             } finally {
>> 243:                 OutputRedirect.checkAndRestoreStderr(ClassCastException.class);
>> 244:             }
> 
> This fails for me, which is not surprising since the snapshot is asynchronous. You probably want to move everything (the suppressStderr and the try/finally with the checkAndRestoreStderr) out of the runAndWait, but even that might not be sufficient without a delay after `latch.getCount()`.

you are right, I missed the `runAndWait()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2360696605

From angorya at openjdk.org  Thu Sep 18 18:50:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 18:50:04 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v11]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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

  run and wait

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/3ed81350..734c2619

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=09-10

  Stats: 110 lines in 1 file changed: 40 ins; 44 del; 26 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From kcr at openjdk.org  Thu Sep 18 20:29:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Sep 2025 20:29:19 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v11]
In-Reply-To: <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>
Message-ID: <nIqtDQBQ6PL_pvXO0SvkgwXpGMNv7hfcNRqnvArcfiU=.5f31d6e2-8e6c-419e-8ae8-ed7b198626af@github.com>

On Thu, 18 Sep 2025 18:50:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run and wait

Shapshot1Test still fails for me. This time the exceptions are being captured in the print stream, but the parsing of the output reports 2 exceptions instead of the expected 1:


    Mismatch in thrown exceptions:
      expected={java.lang.ClassCastException=1}
      observed={java.lang.ClassCastException=1, Exception=1}

tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 253:

> 251: 
> 252:             assertEquals(0, latch.getCount());
> 253:         } finally {

Since the ClassCast exception happens after the latch countdown, I recommend a sleep (of, say, 100 msec) after checking that the latch count is 0.

tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 382:

> 380: 
> 381:             assertEquals(0, latch.getCount());
> 382:         } finally {

Same here: a short sleep after the assertEquals.

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3241971053
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2361081138
PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2361083383

From alexander.matveev at oracle.com  Thu Sep 18 20:33:38 2025
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 18 Sep 2025 20:33:38 +0000
Subject: [External] : RE: Availability of JavaFX build incorporating
 JDK-8366217 fix
In-Reply-To: <002501dc2896$f43c9a10$dcb5ce30$@bigpond.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
 <DM3PPFC82B87818ECC8A922B85853C766CA9917A@DM3PPFC82B87818.namprd10.prod.outlook.com>
 <002501dc2896$f43c9a10$dcb5ce30$@bigpond.com>
Message-ID: <DM3PPFC82B8781851055ED22EC22AD2F3E89916A@DM3PPFC82B87818.namprd10.prod.outlook.com>

Hi Bryon,

Yes, there was some work done on JDK-8305842. Root cause is known, but I did not had time to debug it and fix. If you have ability to convert videos to H.265/HEVC you can use it as a work around for this issue. So far there are no known issues with H.265.

Thanks,
Alexander

From: Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>
Date: Thursday, September 18, 2025 at 5:23?AM
To: Alexander Matveev <alexander.matveev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : RE: Availability of JavaFX build incorporating JDK-8366217 fix
Thank you for your feedback Alexander.

From what I can see there doesn?t seem to have been any, but do you know if there has been any progress towards a resolution of JDK-8305842 and if not, what would trigger activity on that?

I?m surprised JDK-8305842 has remained unresolved because I assume many others must have encountered this bug. I have certainly had ?conversations? with others (https://www.b4x.com/android/forum/threads/javafx-mediaview-under-win11.166839/<https://urldefense.com/v3/__https:/www.b4x.com/android/forum/threads/javafx-mediaview-under-win11.166839/__;!!ACWV5N9M2RV99hQ!JCnnNj8uRaA3gfzORTJZ3XJeHlpNthOAggEWddihqaO7nSmnjYB50x9P5gBbOfidm_OBKlKYmA8aQhImHTSkdBiuVfHp1fnd$> & https://www.b4x.com/android/forum/threads/jmediaview.166994/<https://urldefense.com/v3/__https:/www.b4x.com/android/forum/threads/jmediaview.166994/__;!!ACWV5N9M2RV99hQ!JCnnNj8uRaA3gfzORTJZ3XJeHlpNthOAggEWddihqaO7nSmnjYB50x9P5gBbOfidm_OBKlKYmA8aQhImHTSkdBiuVaBWLA89$>) who have also encountered it. In my case since updating from Win10 to Win 11 earlier this year, I have had to abandon using the feature in my basketball stats display application which shows a sequence of short videos because of the random/intermittent/flaky nature of the symptom and reverted to use of a separate application (vMix) to do this, which is disappointing/inconvenient.

Incidentally, thank you to this community which I find very welcoming and supportive, especially for someone like me who is somewhat out of their depth.

Thanks,

Bryon

From: Alexander Matveev <alexander.matveev at oracle.com>
Sent: Thursday, 18 September 2025 6:36 AM
To: Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>; openjfx-dev at openjdk.org
Subject: Re: Availability of JavaFX build incorporating JDK-8366217 fix

Hi Bryon,

No, JDK-8366217 does not resolve JDK-8305842. JDK-8305842 is still reproducible on Windows 11 with JDK-8366217.

Thanks,
Alexander

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Bryon Dunkley-Smith <bdunkley-smith at bigpond.com<mailto:bdunkley-smith at bigpond.com>>
Date: Tuesday, September 16, 2025 at 6:56?PM
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Availability of JavaFX build incorporating JDK-8366217 fix
Hi All,

Apologies in advance if the terminology in my question is incorrect as I?m somewhat out of my depth here.

I have been monitoring https://bugs.openjdk.org/browse/JDK-8305842 (Video sometimes does not start when reinitializing in Windows 11) for progress with interest because I have a legacy JavaFX based application which has functioned flawlessly for several years, but since upgrading from Win10 to Win1, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media? with success previously and it often runs without error.

So when I saw https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my issue of intermittent/random failures of videos.

I see that ?This pull request has now been integrated.? and being ignorant of how this finds its way into a release of JavaFX, could someone advise me of how I would know if a version (early release?) is available incorporating this ?fix? and where I can download it from.

Thanks,

Bryon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250918/806e1556/attachment-0001.htm>

From angorya at openjdk.org  Thu Sep 18 20:35:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 20:35:02 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v11]
In-Reply-To: <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>
Message-ID: <w8Dz1p04mF6q9xG6F3ntwcT6WRETYb54BcLLJHncH60=.394e6e8b-5cb2-44f5-b8bb-16ead11c14d4@github.com>

On Thu, 18 Sep 2025 18:50:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   run and wait

"Exception is snapshot callback" is coming from 
Node:2421 and Scene:1612

Why in the world do we have unsuppressible System.err.println() in there??

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3309610753

From angorya at openjdk.org  Thu Sep 18 20:41:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 20:41:41 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v12]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <5S80_-_4KnoAl55QeKo0kydJhdGxrd8YMBKZk5PWpgE=.b4faf33c-0d80-4578-99c5-9a0d6f0815cc@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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

  revert snapshot 1 test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/734c2619..25695f5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=10-11

  Stats: 164 lines in 1 file changed: 56 ins; 71 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Thu Sep 18 20:45:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Sep 2025 20:45:52 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v12]
In-Reply-To: <5S80_-_4KnoAl55QeKo0kydJhdGxrd8YMBKZk5PWpgE=.b4faf33c-0d80-4578-99c5-9a0d6f0815cc@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <5S80_-_4KnoAl55QeKo0kydJhdGxrd8YMBKZk5PWpgE=.b4faf33c-0d80-4578-99c5-9a0d6f0815cc@github.com>
Message-ID: <wria7WDUEDqEQB4dPsP3Sqobcc78JAqtCzzb7nuTI10=.48fe83cb-61c8-4659-9bc2-1d8a9a9e0079@github.com>

On Thu, 18 Sep 2025 20:41:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert snapshot 1 test

I decided to remove Snapshot1Test from this PR: there is enough value added already, and there is more work needed to remove stderr output coming from CssParser anyway, so let's postpone it until the next test sprint.

follow up:
[JDK-8368023](https://bugs.openjdk.org/browse/JDK-8368023)
[TestBug] Rework tests to clean up stderr

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3309659879

From jdv at openjdk.org  Fri Sep 19 08:29:35 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 19 Sep 2025 08:29:35 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility
Message-ID: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>

We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.

To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.

Since we wan to capture the test window before test stage is cleared. We are now clearing the test stage and next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` as it overrides the test setup functions.

This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

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

Commit messages:
 - refactor
 - 8367991: Update RegionBackground tests to use ScreenCaptureTestWatcher utility

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

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

From jdv at openjdk.org  Fri Sep 19 10:18:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 19 Sep 2025 10:18:52 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
Message-ID: <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>

> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
> 
> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
> 
> Since we wan to capture the test window before test stage is cleared. We are now clearing the test stage and next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` as it overrides the test setup functions.
> 
> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Add missing initialization logic

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1913/files
  - new: https://git.openjdk.org/jfx/pull/1913/files/00661199..675e3e04

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

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

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

From jbhaskar at openjdk.org  Fri Sep 19 11:53:17 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 19 Sep 2025 11:53:17 GMT
Subject: Integrated: 8271205: [windows] Intermittent test failure in
 test.javafx.scene.web.MiscellaneousTest::testDOMTimer
In-Reply-To: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
References: <8aG7aLuW_by4TygeSsFspmvGi0owjg-X-JZ4QU3FHjE=.c1127694-0d53-4cca-96bc-2edfbc25a928@github.com>
Message-ID: <QziglfFrBLk9bWIPLJ6FP-fpc0YCQxI4oISDXja2fR8=.37a6e06f-c92c-4723-a143-7da1cfe35490@github.com>

On Wed, 17 Sep 2025 02:40:43 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer
> Analysis:
> setTimeout call is not a real-time function. it is considered just a minimum delay before the callback is executed. The actual time taken depends
> 
> How long it takes to process any messages ahead of the already task in the queue?
> Current load on the CPU.
> The number of tasks being executed by the JS engine.
> current state of OS/Browser.
> However, we have to set a minimum timeout value of at least 10 ms, as recommended by Webkit/w3c. Setting value of 1o ms might prevent some un-defined behavior.

This pull request has now been integrated.

Changeset: d7f61be5
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d7f61be5cfba1a551db5769a035b1fa044444956
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8271205: [windows] Intermittent test failure in test.javafx.scene.web.MiscellaneousTest::testDOMTimer

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Fri Sep 19 12:21:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 12:21:56 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
Message-ID: <Zr9P1nxsShozVWWHDlKQt-EtPVVpE7QUYdPrKG2KawI=.041a5cf5-2be1-4611-a95e-81bcfc81e445@github.com>

On Fri, 19 Sep 2025 10:18:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we wan to capture the test window before test stage is cleared. We are now clearing the test stage and next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing initialization logic

This approach requires each test to copy logic from the base class into the test class, so it will be harder to maintain and doesn't scale well.

My recommendation is to either:

1. Make the changes to move the hiding of the changes to the base class methods, change all subclasses that currently have a different `@AfterEach` method _not_named `doSetup` to rename their `@BeforeEach` method to `doSetup()` and call `super.doSetup()` as the first statement of the overridden method
2. Create a protected utility method in VisualTestBase that a subclass can call.

I think 1 might be better, since it keeps all of the logic in the base class, but 2 would be OK as well, since the actual cleaning of the stages would remain in the base class, but it does require overriding the two methods.

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

PR Review: https://git.openjdk.org/jfx/pull/1913#pullrequestreview-3244612867

From lkostyra at openjdk.org  Fri Sep 19 12:49:01 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 19 Sep 2025 12:49:01 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: <rJTP0x--Nsn5Vyou250vumOnCAbCzK1TwGy8BTxC_Po=.7a3ce93e-5ce8-43cf-9a3e-2bb2f0ffef44@github.com>
References: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
 <rJTP0x--Nsn5Vyou250vumOnCAbCzK1TwGy8BTxC_Po=.7a3ce93e-5ce8-43cf-9a3e-2bb2f0ffef44@github.com>
Message-ID: <69WWURTDE-N9sXhD0VsrNKSQM3Ccwy6IVA6P_XScKj8=.8190c659-ac20-446f-bd86-e70ea928439a@github.com>

On Thu, 18 Sep 2025 15:47:03 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> This PR fixes `isFocused()` returning invalid value when Stage fails to receive focus after calling `Stage.show()`. This problem is Windows-only.
>> 
>> In Windows the `SetForegroundWindow()` API lists [a set of conditions to successfully grant focus to a Window](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow#remarks). If any of the conditions are not met, the API will return FALSE. JavaFX did not respect that and instead assumed that receiving `WM_ACTIVATE` with our Window being activated is enough to assume the Window is in focus (which in some cases is not true).
>> 
>> I first tried reacting to `WM_SETFOCUS` and `WM_KILLFOCUS` but it seems those messages are not sent when the window is shown for the first time (instead `WM_ACTIVATE` is used).
>> 
>> To correct this behavior, I noticed the following path is the most reliable:
>> - Call `ShowWindow()` using `SW_SHOWNA` instead of `SW_SHOW` - that makes the window visible but does NOT activate it
>> - Call `SetForegroundWindow()` - that will attempt to give the Window focus and will also activate it if it is successful
>>   - If successful, Java `notifyFocus` callback will be called via `WM_ACTIVATE` handler
>>   - If it fails, we call the `notifyFocus` callback manually informing the upper layers the focus is lost. This establishes the correct state of `Window.focused` property.
>> 
>> With this change I observed that all tests pass as intended as long as two conditions are met (these are needed to satisfy `SetForegroundWindow()` restrictions):
>> - Gradle build is ran without the Gradle daemon
>> - The terminal running Gradle test is in foreground
>> 
>> If any of above two conditions is not met, some tests (including canary test from https://github.com/openjdk/jfx/pull/1804) now timeout/fail when checking whether `Window.isFocused()` is true.
>> 
>> Manually started JavaFX apps (ex. Ensemble) run as they used to and still receive focus upon Stage showing.
>
> I?ve been testing this PR by launching the manual KeyboardTest app.
> 
> 	java @build/run.args tests/manual/events/KeyboardTest.java
> 
> The call to SetForegroundWindow fails but not before activating the window. Since it?s not the foreground window this PR correctly sets the JavaFX focused property back to false. But when I later click on the title bar to bring the window to the foreground the focused property is not updated.
> 
> I?m not sure how we?re expected to detect that our HWND has come to the foreground. There?s no specific message sent when this happens and since the OS thinks the window is already active and focused we don?t get WM_ACTIVATE or WM_SETFOCUS. There?s some messages we could use heuristically (like WM_NCACTIVATE) but I couldn?t find anything more clear cut. I'll keep looking but it doesn't look like Windows makes this easy.

@beldenfox thanks for checking. I remember doing a fair share of looking for a reliable answer to this and couldn't find anything specific, other that SetForegroundWindow being able to fail and having to "handle it". I'll get back to testing this starting next week as well, maybe we'll manage to track down some more reasonable solution.

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3312065779

From lkostyra at openjdk.org  Fri Sep 19 12:51:32 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 19 Sep 2025 12:51:32 GMT
Subject: RFR: 8364117: Skip failing test TableViewContextMenuSortTest on
 Windows
Message-ID: <yLmB7rsfpx4iJUlli2htDkjvOGqttygMaxdDXj2-FbQ=.ce136c79-9ec7-4b97-ba24-c699dc0bb0a7@github.com>

Skipping failing test on Windows only. The problem does not exist on macOS and Linux.

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

Commit messages:
 - 8364117: Skip failing test TableViewContextMenuSortTest on Windows

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

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

From bdunkley-smith at bigpond.com  Fri Sep 19 13:19:22 2025
From: bdunkley-smith at bigpond.com (Bryon Dunkley-Smith)
Date: Fri, 19 Sep 2025 23:19:22 +1000
Subject: [External] : RE: Availability of JavaFX build incorporating
 JDK-8366217 fix
In-Reply-To: <DM3PPFC82B8781851055ED22EC22AD2F3E89916A@DM3PPFC82B87818.namprd10.prod.outlook.com>
References: <000e01dc2776$32a376b0$97ea6410$@bigpond.com>
 <DM3PPFC82B87818ECC8A922B85853C766CA9917A@DM3PPFC82B87818.namprd10.prod.outlook.com>
 <002501dc2896$f43c9a10$dcb5ce30$@bigpond.com>
 <DM3PPFC82B8781851055ED22EC22AD2F3E89916A@DM3PPFC82B87818.namprd10.prod.outlook.com>
Message-ID: <003a01dc2968$04170f70$0c452e50$@bigpond.com>

Thank you Alexander for the update regarding progress on JDK-8305842 and the work around advice.

 

I did a test today using my existing H.264/AVC videos where I triggered the video playing sequence in my application remotely via WiFi every 2 minutes and after 2 hours I had logged many failures to play of individual videos. I re-encoded the 13 relevant videos using Handbrake to H.265/AVEC and repeated the test.

 

To my delight, no errors have been logged and so at least until JDK-8305842 is resolved, I can return to using my application by ensuring any videos are H.265/HEVC and given I have complete control over those videos, that?s not a problem.

 

Thanks again,

 

Bryon

 

From: Alexander Matveev <alexander.matveev at oracle.com> 
Sent: Friday, 19 September 2025 6:34 AM
To: Bryon Dunkley-Smith <bdunkley-smith at bigpond.com>
Cc: openjfx-dev at openjdk.org
Subject: Re: [External] : RE: Availability of JavaFX build incorporating JDK-8366217 fix

 

Hi Bryon,

 

Yes, there was some work done on JDK-8305842. Root cause is known, but I did not had time to debug it and fix. If you have ability to convert videos to H.265/HEVC you can use it as a work around for this issue. So far there are no known issues with H.265.

 

Thanks,

Alexander

 

From: Bryon Dunkley-Smith < <mailto:bdunkley-smith at bigpond.com> bdunkley-smith at bigpond.com>
Date: Thursday, September 18, 2025 at 5:23?AM
To: Alexander Matveev < <mailto:alexander.matveev at oracle.com> alexander.matveev at oracle.com>
Cc:  <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org < <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org>
Subject: [External] : RE: Availability of JavaFX build incorporating JDK-8366217 fix

Thank you for your feedback Alexander.

 

>From what I can see there doesn?t seem to have been any, but do you know if there has been any progress towards a resolution of JDK-8305842 and if not, what would trigger activity on that?

 

I?m surprised JDK-8305842 has remained unresolved because I assume many others must have encountered this bug. I have certainly had ?conversations? with others ( <https://urldefense.com/v3/__https:/www.b4x.com/android/forum/threads/javafx-mediaview-under-win11.166839/__;!!ACWV5N9M2RV99hQ!JCnnNj8uRaA3gfzORTJZ3XJeHlpNthOAggEWddihqaO7nSmnjYB50x9P5gBbOfidm_OBKlKYmA8aQhImHTSkdBiuVfHp1fnd$> https://www.b4x.com/android/forum/threads/javafx-mediaview-under-win11.166839/ &  <https://urldefense.com/v3/__https:/www.b4x.com/android/forum/threads/jmediaview.166994/__;!!ACWV5N9M2RV99hQ!JCnnNj8uRaA3gfzORTJZ3XJeHlpNthOAggEWddihqaO7nSmnjYB50x9P5gBbOfidm_OBKlKYmA8aQhImHTSkdBiuVaBWLA89$> https://www.b4x.com/android/forum/threads/jmediaview.166994/) who have also encountered it. In my case since updating from Win10 to Win 11 earlier this year, I have had to abandon using the feature in my basketball stats display application which shows a sequence of short videos because of the random/intermittent/flaky nature of the symptom and reverted to use of a separate application (vMix) to do this, which is disappointing/inconvenient.

 

Incidentally, thank you to this community which I find very welcoming and supportive, especially for someone like me who is somewhat out of their depth.

 

Thanks,

 

Bryon

 

From: Alexander Matveev < <mailto:alexander.matveev at oracle.com> alexander.matveev at oracle.com> 
Sent: Thursday, 18 September 2025 6:36 AM
To: Bryon Dunkley-Smith < <mailto:bdunkley-smith at bigpond.com> bdunkley-smith at bigpond.com>;  <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org
Subject: Re: Availability of JavaFX build incorporating JDK-8366217 fix

 

Hi Bryon,

 

No, JDK-8366217 does not resolve JDK-8305842. JDK-8305842 is still reproducible on Windows 11 with JDK-8366217.

 

Thanks,

Alexander

 

From: openjfx-dev < <mailto:openjfx-dev-retn at openjdk.org> openjfx-dev-retn at openjdk.org> on behalf of Bryon Dunkley-Smith < <mailto:bdunkley-smith at bigpond.com> bdunkley-smith at bigpond.com>
Date: Tuesday, September 16, 2025 at 6:56?PM
To:  <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org < <mailto:openjfx-dev at openjdk.org> openjfx-dev at openjdk.org>
Subject: Availability of JavaFX build incorporating JDK-8366217 fix

Hi All,

 

Apologies in advance if the terminology in my question is incorrect as I?m somewhat out of my depth here.

 

I have been monitoring  <https://bugs.openjdk.org/browse/JDK-8305842> https://bugs.openjdk.org/browse/JDK-8305842 (Video sometimes does not start when reinitializing in Windows 11) for progress with interest because I have a legacy JavaFX based application which has functioned flawlessly for several years, but since upgrading from Win10 to Win1, there has been intermittent/random failures of videos playing with a ERROR_MEDIA_INVALID being thrown, even though I?ve used the same ?media? with success previously and it often runs without error. 

 

So when I saw  <https://bugs.openjdk.org/browse/JDK-8366217> https://bugs.openjdk.org/browse/JDK-8366217 (Update GStreamer to 1.26.5), I wondered if the update to GStreamer may resolve my issue of intermittent/random failures of videos.

 

I see that ?This pull request has now been integrated.? and being ignorant of how this finds its way into a release of JavaFX, could someone advise me of how I would know if a version (early release?) is available incorporating this ?fix? and where I can download it from.

 

Thanks,

 

Bryon

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

From kcr at openjdk.org  Fri Sep 19 13:21:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 13:21:57 GMT
Subject: RFR: 8364117: Skip failing test TableViewContextMenuSortTest on
 Windows
In-Reply-To: <yLmB7rsfpx4iJUlli2htDkjvOGqttygMaxdDXj2-FbQ=.ce136c79-9ec7-4b97-ba24-c699dc0bb0a7@github.com>
References: <yLmB7rsfpx4iJUlli2htDkjvOGqttygMaxdDXj2-FbQ=.ce136c79-9ec7-4b97-ba24-c699dc0bb0a7@github.com>
Message-ID: <QSyyfCJEt5MF6rYlJVbxN3ixsxipiQiS8Z4GLBmzsTY=.6dc2c3c4-32c5-4261-b9f8-9d38d016cc96@github.com>

On Fri, 19 Sep 2025 12:46:22 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Skipping failing test on Windows only. The problem does not exist on macOS and Linux.

LGTM

No need to wait 24 hours for this simple test skip PR.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1914#pullrequestreview-3244840817

From lkostyra at openjdk.org  Fri Sep 19 13:44:08 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 19 Sep 2025 13:44:08 GMT
Subject: Integrated: 8364117: Skip failing test TableViewContextMenuSortTest on
 Windows
In-Reply-To: <yLmB7rsfpx4iJUlli2htDkjvOGqttygMaxdDXj2-FbQ=.ce136c79-9ec7-4b97-ba24-c699dc0bb0a7@github.com>
References: <yLmB7rsfpx4iJUlli2htDkjvOGqttygMaxdDXj2-FbQ=.ce136c79-9ec7-4b97-ba24-c699dc0bb0a7@github.com>
Message-ID: <YP4i7Cg9A2fw1O-SILxWZu-_916Xi9LUHYp2OuPeFCQ=.8e955fb4-e886-4f06-8579-869a22a83f18@github.com>

On Fri, 19 Sep 2025 12:46:22 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Skipping failing test on Windows only. The problem does not exist on macOS and Linux.

This pull request has now been integrated.

Changeset: 7a488327
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7a488327beb574c84bd68e620d97c2bbe24e335b
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8364117: Skip failing test TableViewContextMenuSortTest on Windows

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Fri Sep 19 15:14:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:14:49 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
Message-ID: <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>

On Fri, 19 Sep 2025 10:18:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we wan to capture the test window before test stage is cleared. We are now clearing the test stage and next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing initialization logic

tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 57:

> 55:     @BeforeEach
> 56:     public void doSetup() {
> 57:         runAndWait(() -> {

suggestion:

we've got `Util::shutdown()` which `hide()`s all the windows then calls `Platform::exit`.

we could add `Util::hideAllWindows(Runnable)` that can be used in these tests, and remove stages from the `VisualTestBase class`:


    /**
     * This synchronous method first hides all the open {@code Window}s in the platform thread,
     * then invokes {@link Platform.exit()}.
     */
    public static void shutdown() {
        hideAllWindows(Platform::exit);
    }

    /// Hides all open `Window`s then invokes `after` (if non-null) in the FX Application Thread.
    public static void hideAllWindows(Runnable after) {
        runAndWait(() -> {
            List.
                copyOf(Window.getWindows()).
                forEach(Window::hide);
            if (after != null) {
                after.run();
            }
        });
    }


What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363246828

From angorya at openjdk.org  Fri Sep 19 15:19:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:19:09 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
Message-ID: <q8I4wrfUbVg-E0_TQMKoDCqFaXax1TM70C4oDlt_q98=.44a27ed0-39ab-4ee9-b6fc-89730a6fb1c6@github.com>

On Fri, 19 Sep 2025 10:18:52 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we wan to capture the test window before test stage is cleared. We are now clearing the test stage and next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing initialization logic

looks good.  left a few minor comments and one suggestion.

tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundFillUITest.java line 88:

> 86:     @AfterEach
> 87:     public void doTeardown() {
> 88: 

please remove empty line

tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 80:

> 78:     @AfterEach
> 79:     public void doTeardown() {
> 80: 

please remove empty line

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

PR Review: https://git.openjdk.org/jfx/pull/1913#pullrequestreview-3245412612
PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363257728
PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363256635

From angorya at openjdk.org  Fri Sep 19 15:21:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:21:24 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
Message-ID: <mh3qstu525YfBBc0L93rocr2Q8mU_2bF3XFCEg-RDm0=.56625abf-c7e8-4d66-a594-cc5a3a7d1000@github.com>

On Sat, 23 Aug 2025 14:26:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Support background loading of raw input streams
>> 
>> - Fixed generics (mix up of two ImageLoader types)
>> - Removed unused code for handling headers, methods, request parameters
>> - Use `long` for progress as streams may exceed 2 GB
>> - Improved documentation of Image regarding background loading
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify documentation with regards to stream closing

this needs a CSR

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3312613703

From kcr at openjdk.org  Fri Sep 19 15:32:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:32:14 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v12]
In-Reply-To: <5S80_-_4KnoAl55QeKo0kydJhdGxrd8YMBKZk5PWpgE=.b4faf33c-0d80-4578-99c5-9a0d6f0815cc@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <5S80_-_4KnoAl55QeKo0kydJhdGxrd8YMBKZk5PWpgE=.b4faf33c-0d80-4578-99c5-9a0d6f0815cc@github.com>
Message-ID: <zR6n9h7sbJfmZknUjM_TNDacqJUbd4u1h9BkSJpEf0k=.228263ec-a012-46e6-823c-b6ba420dcbfd@github.com>

On Thu, 18 Sep 2025 20:41:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert snapshot 1 test

Looks good. My testing shows that there are no more "failed" messages for a successful build and that the number of Exception messages are reduced. The remainder can be handled by the follow-on bug you filed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3242085327

From kcr at openjdk.org  Fri Sep 19 15:32:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:32:15 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v11]
In-Reply-To: <w8Dz1p04mF6q9xG6F3ntwcT6WRETYb54BcLLJHncH60=.394e6e8b-5cb2-44f5-b8bb-16ead11c14d4@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <QEAQfFOFO20GGwE-yFZNaDoABSHNhNGLXdWfn5gYn2Q=.341c75f3-4c1c-48d7-9651-fc4207e3c01f@github.com>
 <w8Dz1p04mF6q9xG6F3ntwcT6WRETYb54BcLLJHncH60=.394e6e8b-5cb2-44f5-b8bb-16ead11c14d4@github.com>
Message-ID: <LjQM23QEPGzQhKU_P_GhTisBgsq5LwKaioiBMENIWqo=.0b924209-16b6-4cbf-af91-2cbf98607383@github.com>

On Thu, 18 Sep 2025 20:32:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> "Exception is snapshot callback" is coming from Node:2421 and Scene:1612
> 
> Why in the world do we have unsuppressible System.err.println() in there??

We have many such places in the JavaFX runtime. We already have a task filed to examine these: [JDK-8320266](https://bugs.openjdk.org/browse/JDK-8320266).

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3312651716

From kcr at openjdk.org  Fri Sep 19 15:32:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:32:19 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
Message-ID: <FzCdc1u0E8_y8n4HP4VYLoE_jiXqrIctuwt_sRUMrac=.d6cb9517-4e96-4887-9e75-9f2c7f7a1269@github.com>

On Thu, 18 Sep 2025 17:44:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   static
>
> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 110:
> 
>> 108: 
>> 109:     @BeforeAll
>> 110:     public static void setUpClass() throws Exception {
> 
> Minor: this method previously didn't have `throws Exception` and probably doesn't need it.

Are you going to revert the "throws Exception" ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2361177235

From kcr at openjdk.org  Fri Sep 19 15:32:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:32:20 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <yz7kbbPpn7wmMdlT11PoEF4lzN_9LjoSrwRGu0-cp7g=.6f3895c5-cb0c-4796-b4a4-ef6feb544bd5@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
 <XnBG4j02yeg6rwAZmTBryoSlIxI-neipuYnGn_L3C4c=.816dbd84-536a-4f22-affd-1df314c94f25@github.com>
 <9QhAWAgIVkTEAql7hRzUe5_9ayK2V7GaAtzll9eK830=.853ec48d-28fc-411c-ac25-36a472adc2df@github.com>
 <yz7kbbPpn7wmMdlT11PoEF4lzN_9LjoSrwRGu0-cp7g=.6f3895c5-cb0c-4796-b4a4-ef6feb544bd5@github.com>
Message-ID: <aOVjuJ9whQ60ooG3Kkjm_anYPJhxRAL2nfW8PCc5qCs=.d5d0b2f3-61e0-4d80-8390-ee8e3e5e68ff@github.com>

On Thu, 18 Sep 2025 18:35:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I doubt it. Anyway, it doesn't really matter all that much.
>
> off topic, but it is more efficient - check out
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/MoreEfficient.java

It might be interesting to see micro-benchmark results, but yeah, off topic.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2363032882

From kcr at openjdk.org  Fri Sep 19 15:41:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:41:28 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
Message-ID: <rnOLuIiwwb51ofx-d0YYWUM6z2w6srF0F0FGbY12Cxg=.802b4b5a-c1d3-496b-bd0e-c1174fed8e13@github.com>

On Fri, 19 Sep 2025 15:37:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> 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 30 additional commits since the last revision:
> 
>  - throws
>  - Merge remote-tracking branch 'origin/master' into 8336332.failed
>  - revert snapshot 1 test
>  - run and wait
>  - review comments
>  - static
>  - review comments
>  - cleanup
>  - reverted renaming
>  - snapshot 1 test
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/92492b29...3d900495

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3245508786

From angorya at openjdk.org  Fri Sep 19 15:41:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:41:27 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

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 30 additional commits since the last revision:

 - throws
 - Merge remote-tracking branch 'origin/master' into 8336332.failed
 - revert snapshot 1 test
 - run and wait
 - review comments
 - static
 - review comments
 - cleanup
 - reverted renaming
 - snapshot 1 test
 - ... and 20 more: https://git.openjdk.org/jfx/compare/92492b29...3d900495

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1897/files
  - new: https://git.openjdk.org/jfx/pull/1897/files/25695f5b..3d900495

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1897&range=11-12

  Stats: 1961 lines in 51 files changed: 1538 ins; 140 del; 283 mod
  Patch: https://git.openjdk.org/jfx/pull/1897.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1897/head:pull/1897

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

From angorya at openjdk.org  Fri Sep 19 15:41:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:41:30 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v9]
In-Reply-To: <FzCdc1u0E8_y8n4HP4VYLoE_jiXqrIctuwt_sRUMrac=.d6cb9517-4e96-4887-9e75-9f2c7f7a1269@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <xyLLtz0FFUbXHZC5l_5cVoGATjylFwUGQ_fmMejj2fQ=.e9848ae6-7967-4037-bcb6-ae76a6649114@github.com>
 <WfEu-ql-TRVsGnQfOQJoIUseF2wl3COVOUkBDlb52KY=.4619a946-fae1-4ae6-a142-0056247c4c64@github.com>
 <FzCdc1u0E8_y8n4HP4VYLoE_jiXqrIctuwt_sRUMrac=.d6cb9517-4e96-4887-9e75-9f2c7f7a1269@github.com>
Message-ID: <vhBu1xgvzBorY1e1D_Q18igvsdiD4aQc6-YCOZ5HxPQ=.931bb243-595f-4d28-99a2-00142d299e91@github.com>

On Thu, 18 Sep 2025 20:53:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 110:
>> 
>>> 108: 
>>> 109:     @BeforeAll
>>> 110:     public static void setUpClass() throws Exception {
>> 
>> Minor: this method previously didn't have `throws Exception` and probably doesn't need it.
>
> Are you going to revert the "throws Exception" ?

done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1897#discussion_r2363326012

From kcr at openjdk.org  Fri Sep 19 15:46:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 15:46:13 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
Message-ID: <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>

On Fri, 19 Sep 2025 15:12:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing initialization logic
>
> tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 57:
> 
>> 55:     @BeforeEach
>> 56:     public void doSetup() {
>> 57:         runAndWait(() -> {
> 
> suggestion:
> 
> we've got `Util::shutdown()` which `hide()`s all the windows then calls `Platform::exit`.
> 
> we could add `Util::hideAllWindows(Runnable)` that can be used in these tests, and remove stages from the `VisualTestBase class`:
> 
> 
>     /**
>      * This synchronous method first hides all the open {@code Window}s in the platform thread,
>      * then invokes {@link Platform.exit()}.
>      */
>     public static void shutdown() {
>         hideAllWindows(Platform::exit);
>     }
> 
>     /// Hides all open `Window`s then invokes `after` (if non-null) in the FX Application Thread.
>     public static void hideAllWindows(Runnable after) {
>         runAndWait(() -> {
>             List.
>                 copyOf(Window.getWindows()).
>                 forEach(Window::hide);
>             if (after != null) {
>                 after.run();
>             }
>         });
>     }
> 
> 
> What do you think?

Seems like a good idea, but I'd recommend doing it as a separate follow-on bug.

Btw, I would add a `Window... windows` parameter and then this would also be useful for test that only want to close a subset of their windows (some such tests have the main stage remain showing throughout the test and don't want that window closed).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363358018

From angorya at openjdk.org  Fri Sep 19 15:49:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Sep 2025 15:49:03 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
 <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
Message-ID: <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>

On Fri, 19 Sep 2025 15:42:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 57:
>> 
>>> 55:     @BeforeEach
>>> 56:     public void doSetup() {
>>> 57:         runAndWait(() -> {
>> 
>> suggestion:
>> 
>> we've got `Util::shutdown()` which `hide()`s all the windows then calls `Platform::exit`.
>> 
>> we could add `Util::hideAllWindows(Runnable)` that can be used in these tests, and remove stages from the `VisualTestBase class`:
>> 
>> 
>>     /**
>>      * This synchronous method first hides all the open {@code Window}s in the platform thread,
>>      * then invokes {@link Platform.exit()}.
>>      */
>>     public static void shutdown() {
>>         hideAllWindows(Platform::exit);
>>     }
>> 
>>     /// Hides all open `Window`s then invokes `after` (if non-null) in the FX Application Thread.
>>     public static void hideAllWindows(Runnable after) {
>>         runAndWait(() -> {
>>             List.
>>                 copyOf(Window.getWindows()).
>>                 forEach(Window::hide);
>>             if (after != null) {
>>                 after.run();
>>             }
>>         });
>>     }
>> 
>> 
>> What do you think?
>
> Seems like a good idea, but I'd recommend doing it as a separate follow-on bug.
> 
> Btw, I would add a `Window... windows` parameter and then this would also be useful for test that only want to close a subset of their windows (some such tests have the main stage remain showing throughout the test and don't want that window closed).

last time I checked, no system test needs to specify which windows to hide.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363373977

From jbhaskar at openjdk.org  Fri Sep 19 16:38:29 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 19 Sep 2025 16:38:29 GMT
Subject: [jfx25u] RFR: 8329874: JavaFX debug builds fail on Linux
Message-ID: <hsJJtqfS2uf1tE9UVcTn2XgBZRN2RWcEfmnmIEpUa58=.844b7033-d996-4552-97a1-de76cfe6661a@github.com>

A clean backport to jfx25u. The patch fixes linux debug build error. The build is ok with fix and fails without fix.

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

Commit messages:
 - Backport 35c1e39cddc6c3d15118b61f99d67f2aba7641c4

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

PR: https://git.openjdk.org/jfx25u/pull/16

From jbhaskar at openjdk.org  Fri Sep 19 16:48:06 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 19 Sep 2025 16:48:06 GMT
Subject: [jfx25u] Integrated: 8329874: JavaFX debug builds fail on Linux
In-Reply-To: <hsJJtqfS2uf1tE9UVcTn2XgBZRN2RWcEfmnmIEpUa58=.844b7033-d996-4552-97a1-de76cfe6661a@github.com>
References: <hsJJtqfS2uf1tE9UVcTn2XgBZRN2RWcEfmnmIEpUa58=.844b7033-d996-4552-97a1-de76cfe6661a@github.com>
Message-ID: <LUttbKgZo1A1q4XUNLMWbNqmL2LWuUHy3lwLAYNlB2Y=.ac5f381c-19ee-49f8-bf02-6a9bafbe9764@github.com>

On Fri, 19 Sep 2025 16:31:17 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx25u. The patch fixes linux debug build error. The build is ok with fix and fails without fix.

This pull request has now been integrated.

Changeset: 1d370f01
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/1d370f0161bcd4f241875c47be3d657c4e563a1f
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8329874: JavaFX debug builds fail on Linux

Backport-of: 35c1e39cddc6c3d15118b61f99d67f2aba7641c4

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

PR: https://git.openjdk.org/jfx25u/pull/16

From kcr at openjdk.org  Fri Sep 19 16:50:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 16:50:15 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
 <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
 <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>
Message-ID: <3xwU3_Z6gYDmvn8K5wIls-Q9wzT4KPqsesrphALVEO0=.dbf7e73b-d5ce-49ef-9cc4-845652fbb899@github.com>

On Fri, 19 Sep 2025 15:46:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Seems like a good idea, but I'd recommend doing it as a separate follow-on bug.
>> 
>> Btw, I would add a `Window... windows` parameter and then this would also be useful for test that only want to close a subset of their windows (some such tests have the main stage remain showing throughout the test and don't want that window closed).
>
> last time I checked, no system test needs to specify which windows to hide.

Maybe not at `@AfterAll` time, but there are tests that close the active window in `@AfterEach` leaving the primary stage shown.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363612579

From kcr at openjdk.org  Fri Sep 19 16:50:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Sep 2025 16:50:17 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <3xwU3_Z6gYDmvn8K5wIls-Q9wzT4KPqsesrphALVEO0=.dbf7e73b-d5ce-49ef-9cc4-845652fbb899@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
 <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
 <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>
 <3xwU3_Z6gYDmvn8K5wIls-Q9wzT4KPqsesrphALVEO0=.dbf7e73b-d5ce-49ef-9cc4-845652fbb899@github.com>
Message-ID: <kwLoR7ng9rlai_zwXM4vkmTZSlSdkPIjY9JrHFFT_rM=.894103c1-4dcf-429c-9c68-fed22c889e2d@github.com>

On Fri, 19 Sep 2025 16:47:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> last time I checked, no system test needs to specify which windows to hide.
>
> Maybe not at `@AfterAll` time, but there are tests that close the active window in `@AfterEach` leaving the primary stage shown.

Anyway, this is another reason why this should be a follow-up issue: so we can discuss the requirements of a more general utility.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2363615765

From jbhaskar at openjdk.org  Fri Sep 19 18:19:09 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 19 Sep 2025 18:19:09 GMT
Subject: [jfx25u] RFR: 8367374: JavaFX debug builds fail on Windows
Message-ID: <no3y5_rlMpOH6EpZngtM9M2RxdgkN1Kxlcqzra5AHD4=.96106ac8-4ec5-459c-8df8-9dd09307b822@github.com>

A clean backport for jfx25u-cpu-open. The Fix solves the debug build error on Windows platform, build works with and fix and fails without fix.

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

Commit messages:
 - Backport 49bece0a566e23b897421d248f2a7aa14aefa58f

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

PR: https://git.openjdk.org/jfx25u/pull/17

From jbhaskar at openjdk.org  Fri Sep 19 18:33:17 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 19 Sep 2025 18:33:17 GMT
Subject: [jfx25u] Integrated: 8367374: JavaFX debug builds fail on Windows
In-Reply-To: <no3y5_rlMpOH6EpZngtM9M2RxdgkN1Kxlcqzra5AHD4=.96106ac8-4ec5-459c-8df8-9dd09307b822@github.com>
References: <no3y5_rlMpOH6EpZngtM9M2RxdgkN1Kxlcqzra5AHD4=.96106ac8-4ec5-459c-8df8-9dd09307b822@github.com>
Message-ID: <cUSLj1D0MXp9N9Gj_wVotJ1gsMnXwFQaRwZMu9dU6Sk=.38c5973f-6e2c-450f-ab05-685ed636b4e5@github.com>

On Fri, 19 Sep 2025 18:11:38 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport for jfx25u-cpu-open. The Fix solves the debug build error on Windows platform, build works with and fix and fails without fix.

This pull request has now been integrated.

Changeset: 39806b54
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/39806b540d1abc6cb5dc95eb9f17841d06f0b514
Stats:     9 lines in 1 file changed: 2 ins; 0 del; 7 mod

8367374: JavaFX debug builds fail on Windows

Backport-of: 49bece0a566e23b897421d248f2a7aa14aefa58f

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

PR: https://git.openjdk.org/jfx25u/pull/17

From mstrauss at openjdk.org  Sat Sep 20 00:26:48 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 20 Sep 2025 00:26:48 GMT
Subject: RFR: 8368166: Media query should accept multiple rules
Message-ID: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>

Given a media query with more than one rule:


@media (prefers-color-scheme: dark) {
    .foo1 {
        -fx-background-color: black;
    }
    .foo2 {
        -fx-background-color: white;
    }
}


The following CSS parser error is encountered: `Expected RBRACE`

The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.

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

Commit messages:
 - fix
 - failing test

Changes: https://git.openjdk.org/jfx/pull/1915/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368166
  Stats: 83 lines in 2 files changed: 55 ins; 26 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1915.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1915/head:pull/1915

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

From michaelstrau2 at gmail.com  Sat Sep 20 01:00:50 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 20 Sep 2025 03:00:50 +0200
Subject: Comments on StageStyle.EXTENDED
Message-ID: <CAJEpuXStF+iRtzG-vfa-Ab908oLuNdfHevv_PKyRHv3m0DvH_g@mail.gmail.com>

This comment was received on the design document for the extended
stage style [0]:

> Linux -> Rounded Corners -> need investigation:
> The biggest issue is, that Gnome, for example, has pretty round
> windows by default, making the app look even more alien (custom
> color scheme and controls). Since I can't adjust the Stage's
> background, I have no means to do corners by myself (which I
> already did, when I created a custom window decoration for the
> app).

This was also brought up by Thiago during the development of this feature [1].
For the extended stage style we're using an undecorated window which
doesn't have rounded corners. What you'd probably need to have for a
custom-drawn approach is a stage style like EXTENDED_TRANSPARENT,
which seems to be very niche. In any case, EXTENDED is a replacement
for DECORATED, which means that it shouldn't be the responsibility of
the application developer to draw window decorations. So we're not
there yet when it comes to rounded window corners on Linux.


> Linux -> window buttons in general:
> On Gnome it's actually pretty rare to have three buttons at all.
> maximised is done via double click on the header, leaving
> minimizing and closing. But I can't change the visibility (or
> order) of the buttons.
> Additionally, native buttons can be configured in which order
> (and on which side) they are. I don't know if the current
> implementation takes that into account.

The current implementation does not take a custom button order into
account, and there is no API to change the button order or visibility.
This might be a future enhancement.

By the way, if you don't want the default buttons, you can pretty
easily bring your own buttons instead (see the documentation of
StageStyle.EXTENDED). If you own the buttons, you can change order and
visibility as you like.


[0] https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
[1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050141.html

From thiago.sayao at gmail.com  Sat Sep 20 09:20:49 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 20 Sep 2025 06:20:49 -0300
Subject: Comments on StageStyle.EXTENDED
In-Reply-To: <CAJEpuXStF+iRtzG-vfa-Ab908oLuNdfHevv_PKyRHv3m0DvH_g@mail.gmail.com>
References: <CAJEpuXStF+iRtzG-vfa-Ab908oLuNdfHevv_PKyRHv3m0DvH_g@mail.gmail.com>
Message-ID: <CAAP_wu=-C35wPi5KZf6yNMQieb4vAQA5zyxGnh4mFYLqS-gRDw@mail.gmail.com>

I attempted to implement rounded corners on GNOME, but ran into some
limitations:

   -

   *JavaFX rendering pipeline*: JavaFX has its own rendering pipeline,
   which cannot be mixed with GTK3?s. Since GTK3 handles rounded corners and
   window clipping through CSS, integrating the two is problematic. I did
   manage a partial solution with some very ugly hacks, but it?s not worth
   pursuing further.
   -

   *GTK4 with DMA-BUF*: On recent GTK4 versions, this becomes possible by
   using *DMA-BUF*. JavaFX could render into a DMA-BUF, which GTK would
   then composite. That would allow a GTK window with a JavaFX scene embedded
   inside it, while still overlaying GTK-based window controls. However, this
   would require major changes, essentially tied to implementing full Wayland
   support. In that case, I?d prefer to go directly with native Wayland (since
   Wayland itself is just a protocol, with compositors like Mutter on GNOME
   and KWin on KDE).
   -

   *GNOME?s CSD approach*: GNOME relies on *Client-Side Decorations (CSD)*,
   meaning the toolkit (GTK) is responsible for drawing window frames and
   controls. This already results in some differences between applications.
   For example, on macOS Tahoe, windows vary in appearance, with larger
   control buttons and different corner radii. Since visual differences are
   acceptable today, one possible approach would be to handle this at
the *JavaFX
   level*:
   -

      Implement a custom Scene or Effect for rounded corner clipping and
      drop shadows.
      -

      On native glass, use set a transparent visual and use
      gdk_window_set_shadow_width to inform the window manager about the
      shadow area, so it won?t treat it as part of the window.



Em sex., 19 de set. de 2025 22:01, Michael Strau? <michaelstrau2 at gmail.com>
escreveu:

> This comment was received on the design document for the extended
> stage style [0]:
>
> > Linux -> Rounded Corners -> need investigation:
> > The biggest issue is, that Gnome, for example, has pretty round
> > windows by default, making the app look even more alien (custom
> > color scheme and controls). Since I can't adjust the Stage's
> > background, I have no means to do corners by myself (which I
> > already did, when I created a custom window decoration for the
> > app).
>
> This was also brought up by Thiago during the development of this feature
> [1].
> For the extended stage style we're using an undecorated window which
> doesn't have rounded corners. What you'd probably need to have for a
> custom-drawn approach is a stage style like EXTENDED_TRANSPARENT,
> which seems to be very niche. In any case, EXTENDED is a replacement
> for DECORATED, which means that it shouldn't be the responsibility of
> the application developer to draw window decorations. So we're not
> there yet when it comes to rounded window corners on Linux.
>
>
> > Linux -> window buttons in general:
> > On Gnome it's actually pretty rare to have three buttons at all.
> > maximised is done via double click on the header, leaving
> > minimizing and closing. But I can't change the visibility (or
> > order) of the buttons.
> > Additionally, native buttons can be configured in which order
> > (and on which side) they are. I don't know if the current
> > implementation takes that into account.
>
> The current implementation does not take a custom button order into
> account, and there is no API to change the button order or visibility.
> This might be a future enhancement.
>
> By the way, if you don't want the default buttons, you can pretty
> easily bring your own buttons instead (see the documentation of
> StageStyle.EXTENDED). If you own the buttons, you can change order and
> visibility as you like.
>
>
> [0] https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
> [1]
> https://mail.openjdk.org/pipermail/openjfx-dev/2024-October/050141.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250920/b490b9fd/attachment-0001.htm>

From tsayao at openjdk.org  Sat Sep 20 09:36:35 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 20 Sep 2025 09:36:35 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v63]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <7FHFe8qkCcxgl71QE4n9HqV4ALFoamL9O-rIoMy_hZk=.63a7d3e5-4a78-4df2-a6da-d17d5ffbd4c5@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:

 - Merge branch 'master' into 8354943
 - Remove unused imports
 - - Fix StageOwnershipTest label + minor adjustments
 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
 - - Fix scene resize when window is unresizable
 - - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view
 - - Fix tests
 - - Fix FOCUS_LOST begin sent on focused windows
 - - Remove CenterOnScreenTest.java
 - ... and 67 more: https://git.openjdk.org/jfx/compare/7a488327...6068f013

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=62
  Stats: 4135 lines in 27 files changed: 2736 ins; 770 del; 629 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 Sep 20 10:00:38 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 20 Sep 2025 10:00:38 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v64]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Revert "8367898: Skip StageFocusTest on Linux"
  
  This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/6068f013..6feb43fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=63
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=62-63

  Stats: 6 lines in 1 file changed: 0 ins; 6 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 kcr at openjdk.org  Sat Sep 20 14:48:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 20 Sep 2025 14:48:32 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <C8OLo0xDH4mHmTrCuSG7seZ8Wy0o3ETyuzi5CQaIn4A=.bc805e27-0d6e-47f2-91aa-c8b61ebf0eab@github.com>

On Mon, 15 Sep 2025 16:20:10 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

This approach seems much better than the previous in that it is activated only when a JavaFX Stage becomes the focused (key) window, and it saves / restores the menu such that whenever an different (e.g., AWT) window is focused, the AWT menu will be installed.

In addition to reviewing and checking that it only touches the menu when it should, testing will be critical.

Reviewers: @kevinrushforth @andy-goryachev-oracle @beldenfox
Cc: @prrace @honkar-jdk

As mentioned above, testing will be key here. This needs to work reliably in the case of a multi-window app when the application is hidden and restored, and when switching between the windows of the app. The automated tests should already cover some of the cases. There may be others to consider.

Here are a few cases that I can think of to check:

* Pure FX app: 2 FX Stages (AWT toolkit not initialized at all) -- the fix should do nothing
* 2 FX Stages with FX initialized first (AWT is initialized last, but no AWT/Swing windows) -- the fix should do nothing
* 2 FX Stages with AWT initialized first (but no AWT/Swing windows) -- the fix should install the FX window when either Stage is focused (there will not be any AWT menu)
* a mix of AWT Windows and FX Stages with FX initialized first -- FX will install the menu and keep it there, since AWT won't install a menu when it doesn't own the NSApplication
* a mix of AWT Windows and FX Stages with FX initialized first -- AWT menu will be installed when an AWT window is active, FX menu will be installed when an FX Stage is active
* 2 AWT Stages one of which has a JFXPanel with an FX scene, initialize AWT first -- fix should be a noop
* 2 AWT Stages one of which has a JFXPanel with an FX scene, initialize FX first -- fix should be a noop

I presume that the automated tests will cover some of these, but we might want additional tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3315012432
PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3315015857

From kcr at openjdk.org  Sat Sep 20 15:17:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 20 Sep 2025 15:17:39 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v2]
In-Reply-To: <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
 <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
Message-ID: <kzE6yb2QvVOyfF733ySqdwxRoFR4ksC7aYz30wip4yY=.5b423b01-7ab4-404b-bf3b-0fee14116084@github.com>

On Tue, 9 Sep 2025 20:26:15 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disabled system test on Linux, DECORATED stage is changing height

The fix looks good. The test fails on Windows with a non-integer HiDPI screen scale. I recommend either choosing values that remain integers when multiplied by 0.25 (that will cover 1, 1.25, 1.5, 1.75, 2, etc) or increase the tolerance used in `assertEquals`.

tests/system/src/test/java/test/javafx/stage/HideIconifiedTest.java line 77:

> 75:     private void assertStageProperties() {
> 76:         assertEquals(STAGE_WIDTH, stage.getWidth(), 0.1, "Stage width changed");
> 77:         assertEquals(STAGE_HEIGHT, stage.getHeight(), 0.1, "Stage height changed");

This fails on a HiDPI system with fractional scale. On my Windows 11 system with 125% scaling, I get this failure, even before the Stage is iconified:

org.opentest4j.AssertionFailedError: Stage height changed ==> expected: <350.0> but was: <350.3999938964844>

This fails because window system snaps the scaled positions and sizes of the window to an integer.

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

PR Review: https://git.openjdk.org/jfx/pull/1889#pullrequestreview-3249088757
PR Review Comment: https://git.openjdk.org/jfx/pull/1889#discussion_r2365675455

From jdv at openjdk.org  Mon Sep 22 06:54:34 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 06:54:34 GMT
Subject: RFR: 8368219: Skip MenuDoubleShortcutTest on macOS & Linux
Message-ID: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>

MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene()/macSceneComesBeforeMenuBar() was failing intermittently and it was made more robust under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405) and it was verified with multiple runs and it was passing.

But looks like we still see this test failing in our CI. We need to skip this test and test fix will be worked upon under [JDK-8368074](https://bugs.openjdk.org/browse/JDK-8368074)

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

Commit messages:
 - 8368219: Skip MenuDoubleShortcutTest on macOS & Linux

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

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

From jdv at openjdk.org  Mon Sep 22 08:02:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 08:02:41 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v3]
In-Reply-To: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
Message-ID: <yUrij9NplW57Ap3Bs4FrRjcCnX7DX8JYIK1RLnMsC0w=.b38e5b97-8629-4636-b299-7cc469aea523@github.com>

> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
> 
> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
> 
> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
> 
> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Move things to baseclass and update all subclasses methods

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1913/files
  - new: https://git.openjdk.org/jfx/pull/1913/files/675e3e04..9c1993c2

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

  Stats: 146 lines in 13 files changed: 23 ins; 103 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1913.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1913/head:pull/1913

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

From duke at openjdk.org  Mon Sep 22 08:45:33 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Mon, 22 Sep 2025 08:45:33 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <1vhDMS4jLlj4WpbEES790QPtcMLzrlCITsWwqp3B4LY=.48031b04-5d17-4926-b67d-408a355c6eda@github.com>

On Mon, 15 Sep 2025 16:20:10 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

Thanks for the test case ideas, my tests cover the AWT initialized first tests, but implementing the other tests You proposed won't be that difficult, as it is just copying the code and moving and deleting some lines.
I will get to add those tests probably until tomorrow.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3317604037

From jdv at openjdk.org  Mon Sep 22 10:22:47 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 10:22:47 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v4]
In-Reply-To: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
Message-ID: <jMrpSifZ-on8qLfXC9YZ7qb_E8KpiB90m1wrpV8Vcak=.6b0c622c-cc15-4353-aa19-6aaec738a4d8@github.com>

> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
> 
> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
> 
> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
> 
> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Add flag to disable stage clearing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1913/files
  - new: https://git.openjdk.org/jfx/pull/1913/files/9c1993c2..0fd10912

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

  Stats: 15 lines in 2 files changed: 7 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1913.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1913/head:pull/1913

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

From jdv at openjdk.org  Mon Sep 22 11:51:35 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 11:51:35 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <Zr9P1nxsShozVWWHDlKQt-EtPVVpE7QUYdPrKG2KawI=.041a5cf5-2be1-4611-a95e-81bcfc81e445@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <Zr9P1nxsShozVWWHDlKQt-EtPVVpE7QUYdPrKG2KawI=.041a5cf5-2be1-4611-a95e-81bcfc81e445@github.com>
Message-ID: <ccrluXXprt8zvrKSgnBW13JquXNBYsmdZ3JvPVmUoMg=.24c00025-4e05-4351-9271-2c11a2031569@github.com>

On Fri, 19 Sep 2025 12:19:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This approach requires each test to copy logic from the base class into the test class, so it will be harder to maintain and doesn't scale well.
> 
> My recommendation is to either:
> 
>     1. Make the changes to move the hiding of the changes to the base class methods, change all subclasses that currently have a different `@BeforeEach` method _not_named `doSetup` to rename their `@BeforeEach` method to `doSetup()` and call `super.doSetup()` as the first statement of the overridden method
> 
>     2. Create a protected utility method in VisualTestBase that a subclass can call.
> 
> 
> I think 1 might be better, since it keeps all of the logic in the base class, but 2 would be OK as well, since the actual cleaning of the stages would remain in the base class, but it does require overriding the two methods.

I have followed the 1st recommendation and updated to include main change in base class and now all sub-classes override the base class setup functions with same name. I have checked all classes which inherit from VisualTestBase and updated them.

Also PointLightIlluminationTest maintains first created stage and uses it for all consecutive tests, so added flag in base class to make sure we re-use the stage. CI headful test run with latest update is green.

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

PR Comment: https://git.openjdk.org/jfx/pull/1913#issuecomment-3318499367

From jdv at openjdk.org  Mon Sep 22 11:58:26 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 11:58:26 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <q8I4wrfUbVg-E0_TQMKoDCqFaXax1TM70C4oDlt_q98=.44a27ed0-39ab-4ee9-b6fc-89730a6fb1c6@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <q8I4wrfUbVg-E0_TQMKoDCqFaXax1TM70C4oDlt_q98=.44a27ed0-39ab-4ee9-b6fc-89730a6fb1c6@github.com>
Message-ID: <DSUfs1eVNI4iMF9ezsvRXQExgWizyyloCGhNqJBKaac=.f5791538-cb3f-4563-94df-b3dc7cdd2d59@github.com>

On Fri, 19 Sep 2025 15:16:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing initialization logic
>
> tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundFillUITest.java line 88:
> 
>> 86:     @AfterEach
>> 87:     public void doTeardown() {
>> 88: 
> 
> please remove empty line

The function itself is removed.

> tests/system/src/test/java/test/robot/javafx/scene/layout/RegionBackgroundImageUITest.java line 80:
> 
>> 78:     @AfterEach
>> 79:     public void doTeardown() {
>> 80: 
> 
> please remove empty line

The function itself is removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2367939753
PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2367939323

From jdv at openjdk.org  Mon Sep 22 11:58:27 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 11:58:27 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <kwLoR7ng9rlai_zwXM4vkmTZSlSdkPIjY9JrHFFT_rM=.894103c1-4dcf-429c-9c68-fed22c889e2d@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
 <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
 <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>
 <3xwU3_Z6gYDmvn8K5wIls-Q9wzT4KPqsesrphALVEO0=.dbf7e73b-d5ce-49ef-9cc4-845652fbb899@github.com>
 <kwLoR7ng9rlai_zwXM4vkmTZSlSdkPIjY9JrHFFT_rM=.894103c1-4dcf-429c-9c68-fed22c889e2d@github.com>
Message-ID: <KIabNJJx4DF4tGHGlqAGQ9F8k-AwUEjTARZmHWmVqyY=.5e8f6c14-2c10-4071-b7e3-45d13174cf05@github.com>

On Fri, 19 Sep 2025 16:48:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Maybe not at `@AfterAll` time, but there are tests that close the active window in `@AfterEach` leaving the primary stage shown.
>
> Anyway, this is another reason why this should be a follow-up issue: so we can discuss the requirements of a more general utility.

I will leave this update to `test.util.Util` for follow up issue.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2367936643

From kcr at openjdk.org  Mon Sep 22 12:28:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 12:28:04 GMT
Subject: RFR: 8368219: Skip MenuDoubleShortcutTest on macOS & Linux
In-Reply-To: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
References: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
Message-ID: <V8Q7cCWkLw783TzPm3odhYEG4i33BMrR4rHH1lFZjeU=.aa026483-4312-4da3-a843-f9eb255d62ab@github.com>

On Mon, 22 Sep 2025 06:48:38 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene()/macSceneComesBeforeMenuBar() was failing intermittently and it was made more robust under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405) and it was verified with multiple runs and it was passing.
> 
> But looks like we still see this test failing in our CI. We need to skip this test and test fix will be worked upon under [JDK-8368074](https://bugs.openjdk.org/browse/JDK-8368074)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1916#pullrequestreview-3252407455

From kcr at openjdk.org  Mon Sep 22 12:53:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 12:53:31 GMT
Subject: RFR: 8368219: Skip MenuDoubleShortcutTest on macOS & Linux
In-Reply-To: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
References: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
Message-ID: <kXRU1JrJG-Q_iKXqrOA2z7AZrs9PgG24vLJt46C_Eeo=.adfa69bc-2255-45b2-aa8a-3486079d74f6@github.com>

On Mon, 22 Sep 2025 06:48:38 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene()/macSceneComesBeforeMenuBar() was failing intermittently and it was made more robust under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405) and it was verified with multiple runs and it was passing.
> 
> But looks like we still see this test failing in our CI. We need to skip this test and test fix will be worked upon under [JDK-8368074](https://bugs.openjdk.org/browse/JDK-8368074)

Since this is a simple addition to skip failing tests, no need to wait 24 hours.

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

PR Comment: https://git.openjdk.org/jfx/pull/1916#issuecomment-3318814413

From jdv at openjdk.org  Mon Sep 22 12:57:09 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 22 Sep 2025 12:57:09 GMT
Subject: Integrated: 8368219: Skip MenuDoubleShortcutTest on macOS & Linux
In-Reply-To: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
References: <tOphchzzcw3ewAamvSRoJOsNzip6kqXUL9KZ9WlFxn4=.19f59f6f-3074-44a5-8a7a-b59389d34185@github.com>
Message-ID: <plMctZ5C0hu_-tqewRWmmTK2nlRMJ-OAPy2xZFSGnQ0=.a6a4b8b3-34bd-4749-adb6-c3b7371442a8@github.com>

On Mon, 22 Sep 2025 06:48:38 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> MenuDoubleShortcutTest > nonMacMenuBarComesBeforeScene()/macSceneComesBeforeMenuBar() was failing intermittently and it was made more robust under [JDK-8364405](https://bugs.openjdk.org/browse/JDK-8364405) and it was verified with multiple runs and it was passing.
> 
> But looks like we still see this test failing in our CI. We need to skip this test and test fix will be worked upon under [JDK-8368074](https://bugs.openjdk.org/browse/JDK-8368074)

This pull request has now been integrated.

Changeset: f2cc78bb
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f2cc78bbf8946e1c9901147d7b7133c7ff5d21eb
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8368219: Skip MenuDoubleShortcutTest on macOS & Linux

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Mon Sep 22 13:28:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 13:28:31 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
Message-ID: <gNKiu_br-B3GbqdDRXYvXXtscrIp7mnPRuJACzMmMyM=.cb1e5c2c-9591-4a85-82f6-db86285fed86@github.com>

On Fri, 19 Sep 2025 15:41:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> 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 30 additional commits since the last revision:
> 
>  - throws
>  - Merge remote-tracking branch 'origin/master' into 8336332.failed
>  - revert snapshot 1 test
>  - run and wait
>  - review comments
>  - static
>  - review comments
>  - cleanup
>  - reverted renaming
>  - snapshot 1 test
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/77dab2e7...3d900495

@arapte Can you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3319030271

From kcr at openjdk.org  Mon Sep 22 14:18:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 14:18:50 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v4]
In-Reply-To: <jMrpSifZ-on8qLfXC9YZ7qb_E8KpiB90m1wrpV8Vcak=.6b0c622c-cc15-4353-aa19-6aaec738a4d8@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <jMrpSifZ-on8qLfXC9YZ7qb_E8KpiB90m1wrpV8Vcak=.6b0c622c-cc15-4353-aa19-6aaec738a4d8@github.com>
Message-ID: <MN3kbiNLgLzEXV5KB4GGyx33XuOO_q2aq_walrwYLCE=.dc995fa1-52f2-4564-a93d-0238e86bd3db@github.com>

On Mon, 22 Sep 2025 10:22:47 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flag to disable stage clearing

LGTM. I left a couple minor comments inline and will reapprove if you make any changes.

tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 85:

> 83:             // Ensure that the scene is really displayed, before the tests begin
> 84:             waitFirstFrame();
> 85:             // The same scene can be used for all the illumination tests by this class

Minor: "scene" --> "stage" ?

tests/system/src/test/java/test/robot/testharness/VisualTestBase.java line 63:

> 61:     Robot robot;
> 62: 
> 63:     protected static boolean clearStage = true;

Minor: would `clearStages` (plural) be a better name?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1913#pullrequestreview-3253080942
PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2368637235
PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2368640274

From kevin.rushforth at oracle.com  Mon Sep 22 15:21:29 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Sep 2025 08:21:29 -0700
Subject: JDK-8210547[linux] Uncontrolled framerate, general frame
 sync/over-calculating animations
In-Reply-To: <e66e87f7-1eca-44ee-8189-2dce95cfbe0b@gmail.com>
References: <e66e87f7-1eca-44ee-8189-2dce95cfbe0b@gmail.com>
Message-ID: <ee44ba34-b227-4d1d-b648-1886a642fdc4@oracle.com>

Redirecting to openjfx-dev which is the right list to discuss technical 
issues such as this.

-- Kevin


On 9/20/2025 8:02 PM, Michael Zucchi wrote:
>
> Morning list!
>
> I hit the above bug[1] a little while ago while using a Transition for 
> timing on a couple of GNU/Linux systems [2,3]. Basically it runs 
> flat-chat because each interpolation call makes changes which triggers 
> a new render pass which then re-runs the animators if they're active, 
> which retriggers another render pass and so on.? Trivial example that 
> demonstrated is below.? If you set a specific frame-rate in the 
> constructor then it doesn't occur. None of the related system 
> properties seem to have any effect.? Tracing through the code I 
> couldn't see how this doesn't always happen with X11/OpenGL, plus 
> there seems to be a bunch of stale/unfinished frame throttling code 
> that never gets run.? I also noticed that gdk_timer was used for frame 
> timing, but this is documented as not being suitable for this task - 
> it lacks suitable resolution and must be reset each call guaranteeing 
> drift.? And in any event timing unlinked from the display will never 
> be accurate.
>
> I developed a small patch to use GLX_SGI_video_sync to synchronise to 
> the actual video frame-rate.? It's probably hooked into the wrong 
> place but i'm not very familiar with the code and couldn't find much 
> documentation on the internals of prism and quantum toolkit; I've 
> attached it as a matter of interest.? With this patch enabled multiple 
> windows will render smoothly matching the video frame rate exactly and 
> the animation calculations are only invoked once per frame apart from 
> wrap-around of cyclic animations (I've only tested with simple scenes).
>
> The main drawback is added latency for low-frame rate monitors (I've 
> tested with a system that can do anything from 25 to 150), and the 
> 'animation now timestamp' is calculated ad-hoc rather than syncing to 
> the expected presentation time.? Having to call glXMakeContext extra 
> times isn't very cheap either, but it's already being called a lot.
>
> With some guidance/pointers I can look further if it would be of use 
> to the project.
>
> Regards,
> ?Michael Z
>
> [1] https://bugs.openjdk.org/browse/JDK-8210547
> [2] gentoo, liunux 6.12.36, AMD Ryzen 4700U APU.
> [3] slackare64-current linux 6.12.29, Ryzen 3900X, Radeon HD7970.
>
> --
> ? ? ? ? ? ? Group g = new Group(new Text("Hello"));
> ? ? ? ? ? ? g.setTranslateX(100);
> ? ? ? ? ? ? g.setTranslateY(100);
> ? ? ? ? ? ? root.getChildren().setAll(g);
> ? ? ? ? ? ? Transition anim = new Transition() {
> ? ? ? ? ? ? ? ? double arg = 0;
>
> ? ? ? ? ? ? ? ? {
> ? ? ? ? ? ? ? ? ? ? setCycleCount(INDEFINITE);
> ? ? ? ? ? ? ? ? ? ? setCycleDuration(Duration.seconds(1));
> ? ? ? ? ? ? ? ? }
>
> ? ? ? ? ? ? ? ? @Override
> ? ? ? ? ? ? ? ? protected void interpolate(double frac) {
> ? ? ? ? ? ? ? ? ? ? g.setRotate(arg++);
> ? ? ? ? ? ? ? ? }
> ? ? ? ? ? ? };
> ? ? ? ? ? ? anim.play(); 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250922/62abc6fe/attachment-0001.htm>

From kevin.rushforth at oracle.com  Mon Sep 22 15:32:55 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Sep 2025 08:32:55 -0700
Subject: JDK-8210547[linux] Uncontrolled framerate, general frame
 sync/over-calculating animations
In-Reply-To: <ee44ba34-b227-4d1d-b648-1886a642fdc4@oracle.com>
References: <e66e87f7-1eca-44ee-8189-2dce95cfbe0b@gmail.com>
 <ee44ba34-b227-4d1d-b648-1886a642fdc4@oracle.com>
Message-ID: <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>

Hi Michael,

Welcome to the openjfx-dev list. We've not ever been able to reproduce 
this on any of our systems. It seems likely that it is specific to 
certain graphics drivers. We do all our testing on Ubuntu Linux and 
Oracle Linux (which is based on RHEL), so it's also possible we are 
testing with different drivers even for the same card.

If you have a reliable patch for the bug, you can submit a PR although 
we will need to find a way to test it. See the CONTRIBUTING [1] 
guidelines for what you will need to do in order to contribute.

Ambarish or Lukasz might have some additional comments.

Thanks.

-- Kevin

[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

On 9/22/2025 8:21 AM, Kevin Rushforth wrote:
> Redirecting to openjfx-dev which is the right list to discuss 
> technical issues such as this.
>
> -- Kevin
>
>
> On 9/20/2025 8:02 PM, Michael Zucchi wrote:
>>
>> Morning list!
>>
>> I hit the above bug[1] a little while ago while using a Transition 
>> for timing on a couple of GNU/Linux systems [2,3]. Basically it runs 
>> flat-chat because each interpolation call makes changes which 
>> triggers a new render pass which then re-runs the animators if 
>> they're active, which retriggers another render pass and so on.? 
>> Trivial example that demonstrated is below.? If you set a specific 
>> frame-rate in the constructor then it doesn't occur. None of the 
>> related system properties seem to have any effect.? Tracing through 
>> the code I couldn't see how this doesn't always happen with 
>> X11/OpenGL, plus there seems to be a bunch of stale/unfinished frame 
>> throttling code that never gets run.? I also noticed that gdk_timer 
>> was used for frame timing, but this is documented as not being 
>> suitable for this task - it lacks suitable resolution and must be 
>> reset each call guaranteeing drift.? And in any event timing unlinked 
>> from the display will never be accurate.
>>
>> I developed a small patch to use GLX_SGI_video_sync to synchronise to 
>> the actual video frame-rate.? It's probably hooked into the wrong 
>> place but i'm not very familiar with the code and couldn't find much 
>> documentation on the internals of prism and quantum toolkit; I've 
>> attached it as a matter of interest.? With this patch enabled 
>> multiple windows will render smoothly matching the video frame rate 
>> exactly and the animation calculations are only invoked once per 
>> frame apart from wrap-around of cyclic animations (I've only tested 
>> with simple scenes).
>>
>> The main drawback is added latency for low-frame rate monitors (I've 
>> tested with a system that can do anything from 25 to 150), and the 
>> 'animation now timestamp' is calculated ad-hoc rather than syncing to 
>> the expected presentation time.? Having to call glXMakeContext extra 
>> times isn't very cheap either, but it's already being called a lot.
>>
>> With some guidance/pointers I can look further if it would be of use 
>> to the project.
>>
>> Regards,
>> ?Michael Z
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8210547
>> [2] gentoo, liunux 6.12.36, AMD Ryzen 4700U APU.
>> [3] slackare64-current linux 6.12.29, Ryzen 3900X, Radeon HD7970.
>>
>> --
>> ? ? ? ? ? ? Group g = new Group(new Text("Hello"));
>> ? ? ? ? ? ? g.setTranslateX(100);
>> ? ? ? ? ? ? g.setTranslateY(100);
>> ? ? ? ? ? ? root.getChildren().setAll(g);
>> ? ? ? ? ? ? Transition anim = new Transition() {
>> ? ? ? ? ? ? ? ? double arg = 0;
>>
>> ? ? ? ? ? ? ? ? {
>> ? ? ? ? ? ? ? ? ? ? setCycleCount(INDEFINITE);
>> ? ? ? ? ? ? ? ? ? ? setCycleDuration(Duration.seconds(1));
>> ? ? ? ? ? ? ? ? }
>>
>> ? ? ? ? ? ? ? ? @Override
>> ? ? ? ? ? ? ? ? protected void interpolate(double frac) {
>> ? ? ? ? ? ? ? ? ? ? g.setRotate(arg++);
>> ? ? ? ? ? ? ? ? }
>> ? ? ? ? ? ? };
>> ? ? ? ? ? ? anim.play(); 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250922/74ebcd38/attachment.htm>

From mfox at openjdk.org  Mon Sep 22 15:36:32 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 22 Sep 2025 15:36:32 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v3]
In-Reply-To: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
Message-ID: <uuWJ2bNoJnBwyybVFdwMwEi74ixvVtr8S8bCbpBLoGk=.490cac35-8d29-465a-9edf-33b03cbeeecf@github.com>

> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Increased test tolerances to account for snapping effects with fractional display scales

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1889/files
  - new: https://git.openjdk.org/jfx/pull/1889/files/77135f53..6658f866

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

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

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

From kcr at openjdk.org  Mon Sep 22 16:56:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 16:56:43 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v3]
In-Reply-To: <uuWJ2bNoJnBwyybVFdwMwEi74ixvVtr8S8bCbpBLoGk=.490cac35-8d29-465a-9edf-33b03cbeeecf@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
 <uuWJ2bNoJnBwyybVFdwMwEi74ixvVtr8S8bCbpBLoGk=.490cac35-8d29-465a-9edf-33b03cbeeecf@github.com>
Message-ID: <EPcUm2ev5nDD_mq_3-VLnwGGlesSfKt3fe41ZQW_fJs=.01d28181-22e7-4b5a-872b-24817daa6471@github.com>

On Mon, 22 Sep 2025 15:36:32 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increased test tolerances to account for snapping effects with fractional display scales

The test passes for me now on my 1.25x scale system. I also checked with 1.75 scale and it also passes.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1889#pullrequestreview-3254052316

From angorya at openjdk.org  Mon Sep 22 17:17:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Sep 2025 17:17:57 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v4]
In-Reply-To: <jMrpSifZ-on8qLfXC9YZ7qb_E8KpiB90m1wrpV8Vcak=.6b0c622c-cc15-4353-aa19-6aaec738a4d8@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <jMrpSifZ-on8qLfXC9YZ7qb_E8KpiB90m1wrpV8Vcak=.6b0c622c-cc15-4353-aa19-6aaec738a4d8@github.com>
Message-ID: <2fax5LOFEr4Z0IRTApQXUNuKOCfZ4KDLAM06ciUv6RY=.d0cda31a-9727-4031-bc4a-715c02e69dc0@github.com>

On Mon, 22 Sep 2025 10:22:47 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flag to disable stage clearing

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1913#pullrequestreview-3254152901

From kcr at openjdk.org  Mon Sep 22 17:44:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 17:44:19 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <b9kv7zeagqo6xD6aQ2vTGjmxbXC0sbOOaEWs_DMJpPQ=.603c80f7-ee03-49d2-9279-012bc35ff112@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

Changes look good to me. I tested on macOS 14 (no change in behavior) and 26 (notification now works where it didn't before).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1895#pullrequestreview-3254273011

From mstrauss at openjdk.org  Mon Sep 22 17:55:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 17:55:18 GMT
Subject: RFR: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <PsTuf_GdbJKj4dEESvgX256sfq0LT38hp1m9UECGXLs=.c02cb637-da3c-45fe-874a-1bf6fae618af@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

I think this fix should be backported to jfx25u.

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

PR Comment: https://git.openjdk.org/jfx/pull/1895#issuecomment-3320493147

From mstrauss at openjdk.org  Mon Sep 22 17:55:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 17:55:19 GMT
Subject: Integrated: 8367370: Accent color platform preference not updating in
 macOS 26 (Tahoe)
In-Reply-To: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
References: <n8j6bjwTyCY43VniTSM7sa-WkRakm2uqiDt58U0LLV4=.ce6a2ca9-69a8-41e7-ac64-b1eb8cad49a9@github.com>
Message-ID: <BQj7d7FPdyg-SdbTXSNo_RnkBhKi3GL0qvWdax2GE5I=.ec6b327f-f0eb-4090-909d-380bf962a385@github.com>

On Wed, 10 Sep 2025 23:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 1. Replace undocumented `AppleColorPreferencesChangedNotification` with `NSSystemColorsDidChangeNotification`.
> 2. Replace undocumented `AppleInterfaceThemeChangedNotification` with a KVO registration for `NSApp.effectiveAppearance`.
> 
> This fix can be tested using either PlatformPreferencesChangedTest, or Monkey Tester > Tools > Platform preferences monitor.

This pull request has now been integrated.

Changeset: 7a4ec274
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7a4ec2744f0398c2cd69a8eb81f89101e5e58925
Stats:     32 lines in 1 file changed: 6 ins; 18 del; 8 mod

8367370: Accent color platform preference not updating in macOS 26 (Tahoe)

Reviewed-by: mfox, kcr

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

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

From kcr at openjdk.org  Mon Sep 22 18:12:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Sep 2025 18:12:19 GMT
Subject: RFR: 8366986: [Win] Incorrect position and size after hiding
 iconified stage [v2]
In-Reply-To: <QyH1wirkIj1Vt4jCYxYeN-iGsdUIDaY4eBBMqD_XUuk=.e4e602c1-cc0d-474b-984a-a81d6299dac7@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
 <elPDizAM1QzRCCwM8E_z_ecrVDao9OVr-2OSV69XraA=.90769fdc-5f8e-4750-8340-b22357220a56@github.com>
 <QyH1wirkIj1Vt4jCYxYeN-iGsdUIDaY4eBBMqD_XUuk=.e4e602c1-cc0d-474b-984a-a81d6299dac7@github.com>
Message-ID: <Jy71EzLwepjRbsvcH_oCgnRUMIs3XAkk94kJkVBKONA=.2340f9d9-9e28-4b9c-82a6-9481764c837c@github.com>

On Wed, 17 Sep 2025 05:43:57 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disabled system test on Linux, DECORATED stage is changing height
>
> LGTM, verified on Windows and macOS 15.

The only change since @lukostyra approved was the increased test tolerance to allow it to pass on systems with a fraction screen scale. As such, a single re-review is sufficient so I'm lowering the number of reviewers to 1.

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

PR Comment: https://git.openjdk.org/jfx/pull/1889#issuecomment-3320601678

From mstrauss at openjdk.org  Mon Sep 22 18:19:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 18:19:01 GMT
Subject: [jfx25u] RFR: 8367370: Accent color platform preference not updating
 in macOS 26 (Tahoe)
Message-ID: <_T5267YI9YdXwnmqPIIekFL3sW6hpYcY502aviVKYck=.a7edf941-32cf-45e5-bd92-518519aaa78f@github.com>

Hi all,

This pull request contains a backport of commit [7a4ec274](https://github.com/openjdk/jfx/commit/7a4ec2744f0398c2cd69a8eb81f89101e5e58925) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Michael Strau? on 22 Sep 2025 and was reviewed by Martin Fox and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 7a4ec2744f0398c2cd69a8eb81f89101e5e58925

Changes: https://git.openjdk.org/jfx25u/pull/18/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=18&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367370
  Stats: 32 lines in 1 file changed: 6 ins; 18 del; 8 mod
  Patch: https://git.openjdk.org/jfx25u/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/18/head:pull/18

PR: https://git.openjdk.org/jfx25u/pull/18

From mstrauss at openjdk.org  Mon Sep 22 18:28:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 18:28:28 GMT
Subject: [jfx25u] RFR: 8367370: Accent color platform preference not
 updating in macOS 26 (Tahoe)
In-Reply-To: <_T5267YI9YdXwnmqPIIekFL3sW6hpYcY502aviVKYck=.a7edf941-32cf-45e5-bd92-518519aaa78f@github.com>
References: <_T5267YI9YdXwnmqPIIekFL3sW6hpYcY502aviVKYck=.a7edf941-32cf-45e5-bd92-518519aaa78f@github.com>
Message-ID: <ONm3fByrAbzsS3-eXExpXME0Umj1RplGqNhN_B6cBbw=.6f890a97-ad61-433c-a4e2-98059a0145d7@github.com>

On Mon, 22 Sep 2025 18:03:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7a4ec274](https://github.com/openjdk/jfx/commit/7a4ec2744f0398c2cd69a8eb81f89101e5e58925) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 22 Sep 2025 and was reviewed by Martin Fox and Kevin Rushforth.
> 
> Thanks!

Maybe the other way around:

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

PR Comment: https://git.openjdk.org/jfx25u/pull/18#issuecomment-3320687473

From mstrauss at openjdk.org  Mon Sep 22 18:43:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 18:43:23 GMT
Subject: [jfx25u] Integrated: 8367370: Accent color platform preference not
 updating in macOS 26 (Tahoe)
In-Reply-To: <_T5267YI9YdXwnmqPIIekFL3sW6hpYcY502aviVKYck=.a7edf941-32cf-45e5-bd92-518519aaa78f@github.com>
References: <_T5267YI9YdXwnmqPIIekFL3sW6hpYcY502aviVKYck=.a7edf941-32cf-45e5-bd92-518519aaa78f@github.com>
Message-ID: <S6uoVwo5HVWTPTyNIP9CoPdnWxpWb9tA2l4XXNt8Qbc=.b88ad88a-4abe-48a7-a5d2-7f2ad808a668@github.com>

On Mon, 22 Sep 2025 18:03:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7a4ec274](https://github.com/openjdk/jfx/commit/7a4ec2744f0398c2cd69a8eb81f89101e5e58925) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 22 Sep 2025 and was reviewed by Martin Fox and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 75ea63da
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/75ea63da7de9b10a3e2d4b6bd50fb2b869f58f0b
Stats:     32 lines in 1 file changed: 6 ins; 18 del; 8 mod

8367370: Accent color platform preference not updating in macOS 26 (Tahoe)

Backport-of: 7a4ec2744f0398c2cd69a8eb81f89101e5e58925

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

PR: https://git.openjdk.org/jfx25u/pull/18

From mfox at openjdk.org  Mon Sep 22 19:28:44 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 22 Sep 2025 19:28:44 GMT
Subject: Integrated: 8366986: [Win] Incorrect position and size after hiding
 iconified stage
In-Reply-To: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
References: <FRQX0pt3ME8MPLTu80-bZ7rGt6pilnC9OKuCGRwGXhA=.e8791540-8691-44f3-b6c1-8fb541d724c1@github.com>
Message-ID: <JOMC-tArZtvfz_e2gxNXlLs8ne53oCOx25ljlLTMrp8=.a0e363e9-4b18-41c8-850a-0e4e5b0e7df4@github.com>

On Tue, 9 Sep 2025 18:40:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When a top-level HWND is iconified its window rect is updated to a hard-coded location (something like -32000, -32000) and a smaller width and height. For this reason we should not send notifyMove or notifyResize events for an iconified stage.  This PR adds a check while handling WM_SHOWWINDOW to catch the case where a stage is hidden while iconified. This matches similar existing checks like the one for WM_MOVE.

This pull request has now been integrated.

Changeset: 4ac4ff6a
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4ac4ff6a4bc38910e8c247dc1904a966cb6c4e91
Stats:     122 lines in 2 files changed: 118 ins; 0 del; 4 mod

8366986: [Win] Incorrect position and size after hiding iconified stage

Reviewed-by: kcr, lkostyra

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

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

From angorya at openjdk.org  Mon Sep 22 23:13:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Sep 2025 23:13:20 GMT
Subject: RFR: 8368166: Media query should accept multiple rules
In-Reply-To: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
Message-ID: <QWczdEYKhcLd5A1pTqUOvcrMp9lvMKGx_CFwnEBZAwA=.80f20b52-83b8-469b-a102-d9d7e48c12ce@github.com>

On Sat, 20 Sep 2025 00:21:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Given a media query with more than one rule:
> 
> 
> @media (prefers-color-scheme: dark) {
>     .foo1 {
>         -fx-background-color: black;
>     }
>     .foo2 {
>         -fx-background-color: white;
>     }
> }
> 
> 
> The following CSS parser error is encountered: `Expected RBRACE`
> 
> The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.

The change looks good, verified with the monkey tester on macOS 15.6.1 M1.

Question:
When I supply a stylesheet with two missing close braces, the master branch complains about `Expected RBRACE at [3,0]` to stderr, the code in this PR does not.

Here is my CSS:

@media (prefers-reduced-motion: reduce) {
  .root { -fx-accent: yellow; }
  .foo { bar: bax; }
    @media (prefers-color-scheme: light) {
      .foo { bar: baxss; }
      .root { -fx-accent: red; }
    }
    @media (prefers-color-scheme: dark) {
      .foo { bar: baxss; }
      .root { -fx-accent: green; }


(the css is updated via `Scene::getStylesheets`)

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3321821697

From mstrauss at openjdk.org  Mon Sep 22 23:52:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 23:52:21 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
Message-ID: <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>

> Given a media query with more than one rule:
> 
> 
> @media (prefers-color-scheme: dark) {
>     .foo1 {
>         -fx-background-color: black;
>     }
>     .foo2 {
>         -fx-background-color: white;
>     }
> }
> 
> 
> The following CSS parser error is encountered: `Expected RBRACE`
> 
> The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.

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

  emit error when closing curly brace is missing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1915/files
  - new: https://git.openjdk.org/jfx/pull/1915/files/e55a76dd..7b1a9d85

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

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

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

From mstrauss at openjdk.org  Mon Sep 22 23:52:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 22 Sep 2025 23:52:22 GMT
Subject: RFR: 8368166: Media query should accept multiple rules
In-Reply-To: <QWczdEYKhcLd5A1pTqUOvcrMp9lvMKGx_CFwnEBZAwA=.80f20b52-83b8-469b-a102-d9d7e48c12ce@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <QWczdEYKhcLd5A1pTqUOvcrMp9lvMKGx_CFwnEBZAwA=.80f20b52-83b8-469b-a102-d9d7e48c12ce@github.com>
Message-ID: <9S8S__Xf-mqve_scZQJFexjV06sTeFIMGfLxicWHgN0=.4ec8b025-1cbe-4cec-9b4d-c39a61d90f63@github.com>

On Mon, 22 Sep 2025 23:10:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Question: When I supply a stylesheet with two missing close braces, the master branch complains about `Expected RBRACE at [3,0]` to stderr, the code in this PR does not.

I've added some code that emits a parser error when a closing curly brace is missing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3321919554

From jdv at openjdk.org  Tue Sep 23 06:07:59 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 06:07:59 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v5]
In-Reply-To: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
Message-ID: <pVwcHXtVTqUytz2hNS3uGbdqXMIYaR74snHlW19Gd24=.d3cc7263-913c-4cc3-ad08-426c39467461@github.com>

> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
> 
> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
> 
> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
> 
> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Rename

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1913/files
  - new: https://git.openjdk.org/jfx/pull/1913/files/0fd10912..ac941267

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

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

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

From jdv at openjdk.org  Tue Sep 23 06:10:33 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 06:10:33 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v2]
In-Reply-To: <KIabNJJx4DF4tGHGlqAGQ9F8k-AwUEjTARZmHWmVqyY=.5e8f6c14-2c10-4071-b7e3-45d13174cf05@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <x9dIosBRAKfme9dUz3e8rWk-DpFiob1JduLM7FjJeAQ=.b5513a7a-b5e3-49ba-99e8-3d69e54c738c@github.com>
 <zb2xCAXguKPuHr7v6Q5qAX4OOEpYHMPa8xvmUt22mVE=.d2739658-03a0-4648-8949-540611454a06@github.com>
 <Jdc9Ietysb1Op6KxW_STpmM9-UTfH3qbZKMHJicjylA=.69909ae2-92f4-47af-8d42-1c135d6ff4bb@github.com>
 <nUW6pHAaLSbvvRMAOyVwwzlfrkNTgefHpFh1CSCwz4I=.d94722be-6390-41dc-9854-a04adc588c14@github.com>
 <3xwU3_Z6gYDmvn8K5wIls-Q9wzT4KPqsesrphALVEO0=.dbf7e73b-d5ce-49ef-9cc4-845652fbb899@github.com>
 <kwLoR7ng9rlai_zwXM4vkmTZSlSdkPIjY9JrHFFT_rM=.894103c1-4dcf-429c-9c68-fed22c889e2d@github.com>
 <KIabNJJx4DF4tGHGlqAGQ9F8k-AwUEjTARZmHWmVqyY=.5e8f6c14-2c10-4071-b7e3-45d13174cf05@github.com>
Message-ID: <BCrJMQOrs_GtvrSgneAcOJQLwAJgWUEGWqiDu-baRiA=.4e385433-f1c5-4ecd-b1c9-40e918c013d1@github.com>

On Mon, 22 Sep 2025 11:55:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Anyway, this is another reason why this should be a follow-up issue: so we can discuss the requirements of a more general utility.
>
> I will leave this update to `test.util.Util` for follow up issue.

Follow-up issue : [JDK-8368363](https://bugs.openjdk.org/browse/JDK-8368363)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1913#discussion_r2371255041

From jdv at openjdk.org  Tue Sep 23 08:02:53 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 08:02:53 GMT
Subject: RFR: 8368375: Skip SWTCursorsTest on Linux & macOS
Message-ID: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>

This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).

We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.

javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.

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

Commit messages:
 - 8368375: Skip SWTCursorsTest on Linux & macOS

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

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

From kcr at openjdk.org  Tue Sep 23 11:08:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 11:08:11 GMT
Subject: RFR: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility [v5]
In-Reply-To: <pVwcHXtVTqUytz2hNS3uGbdqXMIYaR74snHlW19Gd24=.d3cc7263-913c-4cc3-ad08-426c39467461@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
 <pVwcHXtVTqUytz2hNS3uGbdqXMIYaR74snHlW19Gd24=.d3cc7263-913c-4cc3-ad08-426c39467461@github.com>
Message-ID: <SN_tqV5xCTvGSrs8_WrE2hSFUV5bKS2SDS-W4Ipz2Ig=.a0f29cd6-58a3-4fe2-84f5-fc790d7cd228@github.com>

On Tue, 23 Sep 2025 06:07:59 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
>> 
>> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
>> 
>> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
>> 
>> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1913#pullrequestreview-3257406410

From kcr at openjdk.org  Tue Sep 23 11:14:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 11:14:09 GMT
Subject: RFR: 8368375: Skip SWTCursorsTest on Linux & macOS
In-Reply-To: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
Message-ID: <WZ0dh6yY4Z4qxR4W-pxBjAuCkHIGiz63AqpELMw5b4w=.c99f9789-b9fc-4a85-9e05-f320d2312bca@github.com>

On Tue, 23 Sep 2025 07:50:08 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
> 
> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
> 
> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.

Have you run it on Windows enough to know that it is stable there? If so, then this seems fine, although I'm curious as to why you duplicated the platform check logic rather than just calling the PlatformUtil methods.

modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java line 51:

> 49:         System.getProperty("javafx.platform");
> 50:     private static final boolean ANDROID = "android".equals(javafxPlatform) ||
> 51:         "Dalvik".equals(System.getProperty("java.vm.name"));

Is there a reason not to use `PlatformUtil` to do the OS checks?

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

PR Review: https://git.openjdk.org/jfx/pull/1917#pullrequestreview-3257413363
PR Review Comment: https://git.openjdk.org/jfx/pull/1917#discussion_r2371936173

From jdv at openjdk.org  Tue Sep 23 13:07:50 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 13:07:50 GMT
Subject: Integrated: 8367991: Update RegionBackground tests to use
 ScreenCaptureTestWatcher utility
In-Reply-To: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
References: <dRX5T8wI-L72KeQKyqZgyHUTkDeLb1GDbR7PKDY3Jp0=.39d5c2a6-ac8e-4b4a-b5a7-6031c5629494@github.com>
Message-ID: <DExShYnDnezXWcVYqUBGufS5-GgRaFRMKaiMZwrTMTw=.99f7aae6-3af7-483e-9c77-e5ef605a8097@github.com>

On Fri, 19 Sep 2025 08:23:11 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We are seeing very rare intermittent failures in RegionBackgroundFillUITest & RegionBackgroundImageUITest tests in linux. We already have [JDK-8328217](https://bugs.openjdk.org/browse/JDK-8328217) to fix this issue.
> 
> To identify the root cause better, we want to capture the test content when it is failing using ScreenCaptureTestWatcher utility.
> 
> Since we want to capture the test window before test stage is cleared. We are now clearing the test stage in the next test setup. Initially tried updating this behaviour in `VisualTestBase` itself, but that causes tests like `test.robot.test3d.PointLightIlluminationTest` to fail as it overrides the test setup functions.
> 
> This change is tested to make sure ScreenCaptureTestWatcher takes appropriate screen capture on failure and CI full headful test run is green.

This pull request has now been integrated.

Changeset: 405450db
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/405450dbbbf5ef1b7ed63ec54666b0d5d6e90c03
Stats:     76 lines in 12 files changed: 28 ins; 20 del; 28 mod

8367991: Update RegionBackground tests to use ScreenCaptureTestWatcher utility

Reviewed-by: kcr, angorya

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

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

From jdv at openjdk.org  Tue Sep 23 13:22:13 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 13:22:13 GMT
Subject: RFR: 8368375: Skip SWTCursorsTest on Linux & macOS
In-Reply-To: <WZ0dh6yY4Z4qxR4W-pxBjAuCkHIGiz63AqpELMw5b4w=.c99f9789-b9fc-4a85-9e05-f320d2312bca@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <WZ0dh6yY4Z4qxR4W-pxBjAuCkHIGiz63AqpELMw5b4w=.c99f9789-b9fc-4a85-9e05-f320d2312bca@github.com>
Message-ID: <6JBMdeatipdnp0DXKCrQMhp-vv6j3HUNLjJvNAg6PUw=.0f6b056f-4060-4ff2-89ba-a586276f7bac@github.com>

On Tue, 23 Sep 2025 11:11:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Have you run it on Windows enough to know that it is stable there? If so, then this seems fine, although I'm curious as to why you duplicated the platform check logic rather than just calling the PlatformUtil methods.

I was under the impression that after these tests were enabled in [JDK-8169285](https://bugs.openjdk.org/browse/JDK-8169285) we are running them on windows machine in our CI, which is wrong. So this test is not reliable run on windows machine at all. So its better if we just disable this test completely.

Regarding not using PlatformUtil methods : If i import PlatformUtil class in these tests i get `package com.sun.javafx is declared in module javafx.base, which does not export it to the unnamed module`. I tried adding `--add-exports=javafx.base/com.sun.javafx.PlatformUtil=ALL-UNNAMED` in compiler args of swt job, that didn't work out. Also i was not sure whether we need to export this javafx.base class or not. So i went ahead and added utility code in test.

Since we will be disabling this test completely, i will go ahead and remove all PlatformUtil related code.

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

PR Comment: https://git.openjdk.org/jfx/pull/1917#issuecomment-3323992727

From jdv at openjdk.org  Tue Sep 23 13:32:46 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 13:32:46 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
Message-ID: <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>

> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
> 
> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
> 
> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Disable test on all platforms

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1917/files
  - new: https://git.openjdk.org/jfx/pull/1917/files/5a38fa74..d77b91e5

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

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

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

From duke at openjdk.org  Tue Sep 23 15:00:11 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 23 Sep 2025 15:00:11 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v2]
In-Reply-To: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <B6FDkt0eQ7u_0LBKq0WAfXtloASbftAGL62p_5KpBtg=.b7c791e5-9c77-49e2-ad96-ecff159cffe4@github.com>

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:

  8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1904/files
  - new: https://git.openjdk.org/jfx/pull/1904/files/4b687692..6afc5b5b

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

  Stats: 170 lines in 7 files changed: 161 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1904.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1904/head:pull/1904

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

From duke at openjdk.org  Tue Sep 23 15:02:36 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 23 Sep 2025 15:02:36 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <8Gw4pYXFNl5Jf90buHBPr-hrexvkwW3Sc1vjAYaxnGs=.9db7d41c-dbaf-4460-80d1-fa214936c8a9@github.com>

On Mon, 15 Sep 2025 16:20:10 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

So I added most of the tests You proposed, except for the last three. 

For the last two I just need some more time to implement them.

For the other test with AWT being initialized last and still installing the menu is something not directly implemented in this fix. I think AWT won't install a system menu if it is running embedded and therefore this would need its own fix inside AWT itself (but I don't know exactly).

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3324399135

From angorya at openjdk.org  Tue Sep 23 15:12:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 15:12:29 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
Message-ID: <cILqMIfoGu5mMJTp9DI6W6Xzvq0CJisdGgwBmJpY-d8=.74fb60d1-f14d-4a83-b853-4e72bd84da33@github.com>

On Tue, 23 Sep 2025 13:32:46 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
>> 
>> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
>> 
>> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable test on all platforms

Looks good.

Since we are disabling the test on all platforms, this PR's description should probably be updated to remove mentioning of `PlatformUtils`.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1917#pullrequestreview-3258490675

From kcr at openjdk.org  Tue Sep 23 15:24:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 15:24:07 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
Message-ID: <sEi8JbVZDzbKyW-X1As08ls0jY9o5s1dVw4m32ooSAc=.a4283001-a12c-4713-8d7b-8819ddabe3c4@github.com>

On Tue, 23 Sep 2025 13:32:46 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
>> 
>> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
>> 
>> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable test on all platforms

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1917#pullrequestreview-3258539984

From kcr at openjdk.org  Tue Sep 23 15:27:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 15:27:22 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
Message-ID: <hAL1STWXJqurVBK7nowbFN32BZzXfcxX4NRV6QikUlk=.a43d8bb1-b047-4ec1-97c6-dc9f35e8bee2@github.com>

On Tue, 23 Sep 2025 13:32:46 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
>> 
>> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
>> 
>> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable test on all platforms

Since this is just skipping a failing test, no need to wait 24 hours.

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

PR Comment: https://git.openjdk.org/jfx/pull/1917#issuecomment-3324500690

From jdv at openjdk.org  Tue Sep 23 15:39:25 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 15:39:25 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <cILqMIfoGu5mMJTp9DI6W6Xzvq0CJisdGgwBmJpY-d8=.74fb60d1-f14d-4a83-b853-4e72bd84da33@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <nJigw1FsBB2hBw8dF40v5gapI7Ngw-TyAYqnNS8KGsY=.6aa28365-d0fc-45e8-8b7b-fdbae6ba83bc@github.com>
 <cILqMIfoGu5mMJTp9DI6W6Xzvq0CJisdGgwBmJpY-d8=.74fb60d1-f14d-4a83-b853-4e72bd84da33@github.com>
Message-ID: <GBPKDvOZirnGOj9BczHwmBXjkdkmoosF5myyJjs7BYI=.fb12eadf-a6d1-49d8-bdbb-0aa465d6b686@github.com>

On Tue, 23 Sep 2025 15:10:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Looks good.
> 
> Since we are disabling the test on all platforms, this PR's description should probably be updated to remove mentioning of `PlatformUtils`.

I think preserving the description as is maintains the order of commits and why particular decisions were taken during review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1917#issuecomment-3324541998

From jdv at openjdk.org  Tue Sep 23 15:39:27 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 23 Sep 2025 15:39:27 GMT
Subject: Integrated: 8368375: Skip intermittently failing SWTCursorsTest
In-Reply-To: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
Message-ID: <XkjhpuicVhs05FvuEDunPeibN7_7kstsIoueo9Objzk=.ca5a7cb9-da6e-4c6f-83ab-b2d4e0fc042c@github.com>

On Tue, 23 Sep 2025 07:50:08 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> This test is failing intermittently on macOS and Linux platforms and it will be fixed under [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599).
> 
> We need to skip this until [JDK-8367599](https://bugs.openjdk.org/browse/JDK-8367599) is fixed.
> 
> javafx.base/com.sun.javafx.PlatformUtil helps to determine individual platforms on which test is running. But this module is exposed only to system tests and not to SWT tests. So i am replicating this test utility code in SWTCursorsTest.

This pull request has now been integrated.

Changeset: 8f4d7a01
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8f4d7a0102800ed4c191fc7046a9005addd3fa94
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8368375: Skip intermittently failing SWTCursorsTest

Reviewed-by: kcr, angorya

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

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

From kcr at openjdk.org  Tue Sep 23 15:49:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 15:49:45 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <6JBMdeatipdnp0DXKCrQMhp-vv6j3HUNLjJvNAg6PUw=.0f6b056f-4060-4ff2-89ba-a586276f7bac@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <WZ0dh6yY4Z4qxR4W-pxBjAuCkHIGiz63AqpELMw5b4w=.c99f9789-b9fc-4a85-9e05-f320d2312bca@github.com>
 <6JBMdeatipdnp0DXKCrQMhp-vv6j3HUNLjJvNAg6PUw=.0f6b056f-4060-4ff2-89ba-a586276f7bac@github.com>
Message-ID: <8Cymdky1ocIE0X7Gh9m9sCqX_uJThXzdWH2VYjy8UkQ=.6bcd308d-9d5f-41b7-929b-f932fb096e32@github.com>

On Tue, 23 Sep 2025 13:19:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Regarding not using PlatformUtil methods : If i import PlatformUtil class in these tests i get `package com.sun.javafx is declared in module javafx.base, which does not export it to the unnamed module`. I tried adding `--add-exports=javafx.base/com.sun.javafx.PlatformUtil=ALL-UNNAMED` in compiler args of swt job, that didn't work out. Also i was not sure whether we need to export this javafx.base class or not. So i went ahead and added utility code in test.
> 
> Since we will be disabling this test completely, i will go ahead and remove all PlatformUtil related code.

As you say, this is no longer needed for this PR. If something like this arises in the future, the way to add the needed export is to create a `modules/javafx.swt/src/test/addExports` file (the system tests and most of the modules already have one, but `javafx.swt` does not) and the add the following line:


--add-exports javafx.base/com.sun.javafx=ALL-UNNAMED


(note that exports are done at the package level not per class)

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

PR Comment: https://git.openjdk.org/jfx/pull/1917#issuecomment-3324590689

From kcr at openjdk.org  Tue Sep 23 15:49:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 23 Sep 2025 15:49:45 GMT
Subject: RFR: 8368375: Skip intermittently failing SWTCursorsTest [v2]
In-Reply-To: <6JBMdeatipdnp0DXKCrQMhp-vv6j3HUNLjJvNAg6PUw=.0f6b056f-4060-4ff2-89ba-a586276f7bac@github.com>
References: <N77DxSeZeNajiSYQNBSFQHZ40r5iolYc2fK8neNG5ak=.57196623-ca9a-4eb8-938a-becd25c023a7@github.com>
 <WZ0dh6yY4Z4qxR4W-pxBjAuCkHIGiz63AqpELMw5b4w=.c99f9789-b9fc-4a85-9e05-f320d2312bca@github.com>
 <6JBMdeatipdnp0DXKCrQMhp-vv6j3HUNLjJvNAg6PUw=.0f6b056f-4060-4ff2-89ba-a586276f7bac@github.com>
Message-ID: <8Cymdky1ocIE0X7Gh9m9sCqX_uJThXzdWH2VYjy8UkQ=.6bcd308d-9d5f-41b7-929b-f932fb096e32@github.com>

On Tue, 23 Sep 2025 13:19:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Regarding not using PlatformUtil methods : If i import PlatformUtil class in these tests i get `package com.sun.javafx is declared in module javafx.base, which does not export it to the unnamed module`. I tried adding `--add-exports=javafx.base/com.sun.javafx.PlatformUtil=ALL-UNNAMED` in compiler args of swt job, that didn't work out. Also i was not sure whether we need to export this javafx.base class or not. So i went ahead and added utility code in test.
> 
> Since we will be disabling this test completely, i will go ahead and remove all PlatformUtil related code.

As you say, this is no longer needed for this PR. If something like this arises in the future, the way to add the needed export is to create a `modules/javafx.swt/src/test/addExports` file (the system tests and most of the modules already have one, but `javafx.swt` does not) and the add the following line:


--add-exports javafx.base/com.sun.javafx=ALL-UNNAMED


(note that exports are done at the package level not per class)

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

PR Comment: https://git.openjdk.org/jfx/pull/1917#issuecomment-3324590689

From angorya at openjdk.org  Tue Sep 23 16:28:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 16:28:50 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
Message-ID: <ILt8MVXhP30JQogz2gS2sb9nIEtcVlI-3p77Jy5AwRw=.8630f1ad-9e88-4f97-bcf3-acaa2da35112@github.com>

On Mon, 22 Sep 2025 23:52:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Given a media query with more than one rule:
>> 
>> 
>> @media (prefers-color-scheme: dark) {
>>     .foo1 {
>>         -fx-background-color: black;
>>     }
>>     .foo2 {
>>         -fx-background-color: white;
>>     }
>> }
>> 
>> 
>> The following CSS parser error is encountered: `Expected RBRACE`
>> 
>> The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   emit error when closing curly brace is missing

Than you for updating the error message!

What are the numbers in square brackets?  Is it sufficient for the user to determine where the problem is?

For example, when I enter a single '{' in the monkey tester CSS Playground -> Custom CSS field, I get the following output:

`WARNING: CSS Error parsing '{: Expected RBRACE at [-1,-1]`

what does `[-1,-1]` refer to?

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3324744582

From mstrauss at openjdk.org  Tue Sep 23 16:37:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 23 Sep 2025 16:37:04 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <ILt8MVXhP30JQogz2gS2sb9nIEtcVlI-3p77Jy5AwRw=.8630f1ad-9e88-4f97-bcf3-acaa2da35112@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
 <ILt8MVXhP30JQogz2gS2sb9nIEtcVlI-3p77Jy5AwRw=.8630f1ad-9e88-4f97-bcf3-acaa2da35112@github.com>
Message-ID: <hSbH11dQwN0HP3ot53Q9JMfumtCy4pmoHZT53og8Iu0=.1f301cda-e2df-47ab-b1f3-bdde7d7dafcf@github.com>

On Tue, 23 Sep 2025 16:26:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Than you for updating the error message!
> 
> What are the numbers in square brackets? Is it sufficient for the user to determine where the problem is?
> 
> For example, when I enter a single '{' in the monkey tester CSS Playground -> Custom CSS field, I get the following output:
> 
> `WARNING: CSS Error parsing '{: Expected RBRACE at [-1,-1]`
> 
> what does `[-1,-1]` refer to?

It's the line and column number. [-1,-1] means that the CSS parser doesn't know where the error is. One of the many deficiencies of the CSS implementation.

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3324774022

From arapte at openjdk.org  Tue Sep 23 16:37:07 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 23 Sep 2025 16:37:07 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
Message-ID: <VSMbH1M9w48Py7RJH4ZP_ZZqCAkPeqbOmXIJKiQUcVY=.6fb9ca72-739f-4b80-9429-e6992cd72c91@github.com>

On Fri, 19 Sep 2025 15:41:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> 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 30 additional commits since the last revision:
> 
>  - throws
>  - Merge remote-tracking branch 'origin/master' into 8336332.failed
>  - revert snapshot 1 test
>  - run and wait
>  - review comments
>  - static
>  - review comments
>  - cleanup
>  - reverted renaming
>  - snapshot 1 test
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/01a8785a...3d900495

LGTM+, The log looks good now.

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3258823334

From angorya at openjdk.org  Tue Sep 23 16:43:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 16:43:10 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
Message-ID: <PBeITyUBQBOYrOCrDoni5PBozKWgrnQI8TFecxUQAgU=.a8751e07-c9d6-4d63-a3b0-53c86c211926@github.com>

On Mon, 22 Sep 2025 23:52:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Given a media query with more than one rule:
>> 
>> 
>> @media (prefers-color-scheme: dark) {
>>     .foo1 {
>>         -fx-background-color: black;
>>     }
>>     .foo2 {
>>         -fx-background-color: white;
>>     }
>> }
>> 
>> 
>> The following CSS parser error is encountered: `Expected RBRACE`
>> 
>> The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   emit error when closing curly brace is missing

Marked as reviewed by angorya (Reviewer).

Is this just a matter of initializing the values to [0,0] perhaps?

Regardless, I think the current changes are acceptable.  Thanks for clarifications!

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

PR Review: https://git.openjdk.org/jfx/pull/1915#pullrequestreview-3258844299
PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3324796467

From mstrauss at openjdk.org  Tue Sep 23 16:50:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 23 Sep 2025 16:50:38 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <PBeITyUBQBOYrOCrDoni5PBozKWgrnQI8TFecxUQAgU=.a8751e07-c9d6-4d63-a3b0-53c86c211926@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
 <PBeITyUBQBOYrOCrDoni5PBozKWgrnQI8TFecxUQAgU=.a8751e07-c9d6-4d63-a3b0-53c86c211926@github.com>
Message-ID: <AgHamgiB66How1AqrOm4mpvUYt30pzoJGFvOrqa2W14=.f6a4d67b-14bc-4c2e-a156-65bde1768a03@github.com>

On Tue, 23 Sep 2025 16:40:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Is this just a matter of initializing the values to [0,0] perhaps?
> 
> Regardless, I think the current changes are acceptable. Thanks for clarifications!

This happens when `currentToken` is null, which probably (only?) happens at the end of the token stream. So the last column of the last line would be a better choice than [0,0].

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3324817788

From arapte at openjdk.org  Tue Sep 23 18:01:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 23 Sep 2025 18:01:29 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
Message-ID: <ePoebsNblEIi9fmKeT5pfWBgbc1H721_Pw7Rrftr1G8=.a1db1196-126b-4a7e-bb25-cdc3dc2029a3@github.com>

On Fri, 19 Sep 2025 15:41:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> 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 30 additional commits since the last revision:
> 
>  - throws
>  - Merge remote-tracking branch 'origin/master' into 8336332.failed
>  - revert snapshot 1 test
>  - run and wait
>  - review comments
>  - static
>  - review comments
>  - cleanup
>  - reverted renaming
>  - snapshot 1 test
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/15feb7df...3d900495

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1897#pullrequestreview-3259080289

From angorya at openjdk.org  Tue Sep 23 18:06:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 18:06:47 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <AgHamgiB66How1AqrOm4mpvUYt30pzoJGFvOrqa2W14=.f6a4d67b-14bc-4c2e-a156-65bde1768a03@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
 <PBeITyUBQBOYrOCrDoni5PBozKWgrnQI8TFecxUQAgU=.a8751e07-c9d6-4d63-a3b0-53c86c211926@github.com>
 <AgHamgiB66How1AqrOm4mpvUYt30pzoJGFvOrqa2W14=.f6a4d67b-14bc-4c2e-a156-65bde1768a03@github.com>
Message-ID: <9VK02l6Xn-LyfF7_g5y_5CUF2mJw0Btu7B8EQZcHcI8=.3a31c47c-55a0-44e3-ae50-c769190f1ee2@github.com>

On Tue, 23 Sep 2025 16:47:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> So the last column of the last line would be a better choice than [0,0].

Right, the general idea is to show the correct information to the user.  It can either be addressed this as a part of this PR or a follow up.

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3325034939

From angorya at openjdk.org  Tue Sep 23 18:15:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 18:15:39 GMT
Subject: RFR: 8336332: Rework tests to avoid unrelated stderr output [v13]
In-Reply-To: <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
 <sYLcHNjOcdkG-oN6S3jHQgMG8O2itTrOPCBvN7BliVI=.7a751312-4b46-466e-a2c3-1ad22643059e@github.com>
Message-ID: <f2d_QtUKSVLBFTZC-Ub0JcSmApBfQmtp0fqiLnHlxmg=.a34dbd55-c5b3-46bd-ac64-b9b974f5ec0b@github.com>

On Fri, 19 Sep 2025 15:41:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
>> 
>> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
>> 
>> ## How To
>> 
>> To redirect stderr and later check the exceptions, surround your code with
>> 
>> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
>> 
>> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
>> 
>> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
>> 
>> ## Changes
>> 
>> - added `OutputRedirect` facility
>> 
>> ## Miscellaneous
>> 
>> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995
>
> 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 30 additional commits since the last revision:
> 
>  - throws
>  - Merge remote-tracking branch 'origin/master' into 8336332.failed
>  - revert snapshot 1 test
>  - run and wait
>  - review comments
>  - static
>  - review comments
>  - cleanup
>  - reverted renaming
>  - snapshot 1 test
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/f4612a68...3d900495

thank you for reviewing!

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

PR Comment: https://git.openjdk.org/jfx/pull/1897#issuecomment-3325049777

From angorya at openjdk.org  Tue Sep 23 18:15:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 18:15:40 GMT
Subject: Integrated: 8336332: Rework tests to avoid unrelated stderr output
In-Reply-To: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
References: <RmCLH5rYg_xI9LHj7_WBtr7J6Gpf_vK84Exd1c_-T5s=.8076a7b2-2095-4ff7-8c4e-894acf15469a@github.com>
Message-ID: <lZ_0B057_5UrojekVhD130Bmg3DOa4z15BntDqGq1t0=.25bef6ea-0482-48a5-a619-f90bfe24c2c1@github.com>

On Thu, 11 Sep 2025 22:09:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This PR removes unrelated `stderr` output in the headless test logs by redirecting it to an in-memory buffer.  Exceptions found in the buffer can be checked against the expected list.
> 
> In the case when any mismatch is detected, whether the type or the number of exceptions of particular type, the accumulated buffer gets dumped to `stderr` and the test fails.
> 
> ## How To
> 
> To redirect stderr and later check the exceptions, surround your code with
> 
> `OutputRedirect.suppressStderr()` and either `OutputRedirect.checkStderr()` or `OutputRedirect.checkAndRestoreStderr()` (ideally, in the `finally` block).
> 
> To simply undo redirection, without checking, call  `OutputRedirect.restoreStderr()`.
> 
> To add the check to all the tests in the file, one can call the above mentioned methods inside  `@BeforeEach` and `@AfterEach`.
> 
> ## Changes
> 
> - added `OutputRedirect` facility
> 
> ## Miscellaneous
> 
> `ErrorLoggingUtiltity` name will be fixed in a followup https://bugs.openjdk.org/browse/JDK-8367995

This pull request has now been integrated.

Changeset: f4b3d552
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f4b3d55200d519c89f34f0c30f15e1da0323efc0
Stats:     494 lines in 18 files changed: 433 ins; 19 del; 42 mod

8336332: Rework tests to avoid unrelated stderr output

Reviewed-by: kcr, arapte

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

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

From angorya at openjdk.org  Tue Sep 23 18:41:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Sep 2025 18:41:45 GMT
Subject: RFR: 8367995: [TestBug] Rename ErrorLoggingUtiltity
Message-ID: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>

The follow-up to #1897: fixing spelling of `ErrorLoggingUtiltity`.

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

Commit messages:
 - spelling

Changes: https://git.openjdk.org/jfx/pull/1912/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1912&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367995
  Stats: 729 lines in 13 files changed: 71 ins; 71 del; 587 mod
  Patch: https://git.openjdk.org/jfx/pull/1912.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1912/head:pull/1912

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

From me at fouad.io  Thu Sep 18 11:10:34 2025
From: me at fouad.io (Fouad Almalki)
Date: Thu, 18 Sep 2025 14:10:34 +0300
Subject: JavaFX 25 HeaderBar RTL bug on Windows
Message-ID: <CAJ7JGjYs+V9D9xm9DobSHBtZVKK8_NDi62WWtGEkWpokojq3HA@mail.gmail.com>

Hi,

I just tried the new HeaderBar on Windows 11, but it seems that it doesn't
work properly with a RTL stage.
Here is a video that shows the bug:
https://www.youtube.com/watch?v=hoZRQ8Hl-6s


Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250918/12c071a7/attachment-0001.htm>

From 1987803602 at qq.com  Tue Sep 23 10:10:14 2025
From: 1987803602 at qq.com (=?utf-8?B?enph?=)
Date: Tue, 23 Sep 2025 18:10:14 +0800
Subject: =?utf-8?B?QSBidWcgZm9yIFJpY2hUZXh0QXJlYe+8jGNhbiBu?=
 =?utf-8?B?b3QgaW5wdXQgY2hpbmVzZSBvbiBtYWNvcyBwbGF0?=
 =?utf-8?B?Zm9ybSA=?=
Message-ID: <tencent_293727B74CD313F1C157B62D6971C3D05A07@qq.com>

Dear jfx developers, hello. I would like to submit a bug regarding jfx RichTextArea
As shown in the video or GIF, in the macOS system, the Chinese input method does not work and cannot input Chinese in the richtextarea, but it works normally in the textfield
Moreover, in the Windows system, richtextarea works normally and we hope to fix this issue



zza
1987803602 at qq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/9345e013/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C03125F7 at D66F897A.0672D26800000000.gif
Type: image/gif
Size: 1848711 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/9345e013/C03125F7D66F897A.0672D26800000000-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??2025-09-23 17.18.57.mov
Type: application/octet-stream
Size: 1468562 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/9345e013/2025-09-2317.18.57-0001.mov>

From kevin.rushforth at oracle.com  Tue Sep 23 19:49:16 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 23 Sep 2025 12:49:16 -0700
Subject: JavaFX 25 HeaderBar RTL bug on Windows
In-Reply-To: <CAJ7JGjYs+V9D9xm9DobSHBtZVKK8_NDi62WWtGEkWpokojq3HA@mail.gmail.com>
References: <CAJ7JGjYs+V9D9xm9DobSHBtZVKK8_NDi62WWtGEkWpokojq3HA@mail.gmail.com>
Message-ID: <463887bc-0837-4518-90c2-4e77d0f46d65@oracle.com>

This was filed as https://bugs.openjdk.org/browse/JDK-8368021

-- Kevin


On 9/18/2025 4:10 AM, Fouad Almalki wrote:
> Hi,
>
> I just tried the new HeaderBar on Windows 11, but it seems that it 
> doesn't work properly with a RTL stage.
> Here is a video that shows the bug: 
> https://www.youtube.com/watch?v=hoZRQ8Hl-6s
>
>
> Thanks.


From kevin.rushforth at oracle.com  Tue Sep 23 19:52:12 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 23 Sep 2025 12:52:12 -0700
Subject: =?UTF-8?Q?Re=3A_A_bug_for_RichTextArea=EF=BC=8Ccan_not_input_chines?=
 =?UTF-8?Q?e_on_macos_platform?=
In-Reply-To: <tencent_293727B74CD313F1C157B62D6971C3D05A07@qq.com>
References: <tencent_293727B74CD313F1C157B62D6971C3D05A07@qq.com>
Message-ID: <8dd558e2-1334-4f88-944f-cf2aaaa19329@oracle.com>

I see that Andy filed this as https://bugs.openjdk.org/browse/JDK-8368478

-- Kevin


On 9/23/2025 3:10 AM, zza wrote:
> Dear jfx developers, hello. I would like to submit a bug regarding jfx 
> RichTextArea
> As shown in the video or GIF, in the macOS system, the Chinese input 
> method does not work and cannot input Chinese in the richtextarea, but 
> it works normally in the textfield
> Moreover, in the Windows system, richtextarea works normally and we 
> hope to fix this issue
> 	
> zza
> 1987803602 at qq.com
>
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=zza&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQWfJFjZBGoZCYGBiaymlF3l02q9XCSptkeWuJD0KficKOalgKicaicjUPI9MKuOvFQbU13JCjzy%2F0&mail=1987803602%40qq.com&code=0ZHFk9vX4rcfgTq6JdF4ifl3fBHRTnJGk0lR7pQTJacEtaXibWUSS4deNRsELhaQOHQAGDCrXwoRnjGFSkoL6Q>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/e6543e4a/attachment.htm>

From andy.goryachev at oracle.com  Tue Sep 23 19:52:54 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 23 Sep 2025 19:52:54 +0000
Subject: =?iso-2022-jp?B?UmU6IEEgYnVnIGZvciBSaWNoVGV4dEFyZWEbJEIhJBsoQmNhbiBub3Qg?=
 =?iso-2022-jp?B?aW5wdXQgY2hpbmVzZSBvbiBtYWNvcyBwbGF0Zm9ybSA=?=
In-Reply-To: <tencent_293727B74CD313F1C157B62D6971C3D05A07@qq.com>
References: <tencent_293727B74CD313F1C157B62D6971C3D05A07@qq.com>
Message-ID: <CY8PR10MB7265120AC13C35E38FC8EE5AE51DA@CY8PR10MB7265.namprd10.prod.outlook.com>

Thank you, this was filed earlier as https://bugs.openjdk.org/browse/JDK-8368478

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of zza <1987803602 at qq.com>
Date: Tuesday, September 23, 2025 at 12:45
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: A bug for RichTextArea?can not input chinese on macos platform

Dear jfx developers, hello. I would like to submit a bug regarding jfx RichTextArea
As shown in the video or GIF, in the macOS system, the Chinese input method does not work and cannot input Chinese in the richtextarea, but it works normally in the textfield
Moreover, in the Windows system, richtextarea works normally and we hope to fix this issue
[cid:C03125F7 at D66F897A.0672D26800000000.gif]
[http://thirdqq.qlogo.cn/ek_qqapp/AQWfJFjZBGoZCYGBiaymlF3l02q9XCSptkeWuJD0KficKOalgKicaicjUPI9MKuOvFQbU13JCjzy/0]<https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=zza&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQWfJFjZBGoZCYGBiaymlF3l02q9XCSptkeWuJD0KficKOalgKicaicjUPI9MKuOvFQbU13JCjzy%2F0&mail=1987803602%40qq.com&code=0ZHFk9vX4rcfgTq6JdF4ifl3fBHRTnJGk0lR7pQTJacEtaXibWUSS4deNRsELhaQOHQAGDCrXwoRnjGFSkoL6Q>
zza<https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=zza&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQWfJFjZBGoZCYGBiaymlF3l02q9XCSptkeWuJD0KficKOalgKicaicjUPI9MKuOvFQbU13JCjzy%2F0&mail=1987803602%40qq.com&code=0ZHFk9vX4rcfgTq6JdF4ifl3fBHRTnJGk0lR7pQTJacEtaXibWUSS4deNRsELhaQOHQAGDCrXwoRnjGFSkoL6Q>
1987803602 at qq.com<https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=zza&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQWfJFjZBGoZCYGBiaymlF3l02q9XCSptkeWuJD0KficKOalgKicaicjUPI9MKuOvFQbU13JCjzy%2F0&mail=1987803602%40qq.com&code=0ZHFk9vX4rcfgTq6JdF4ifl3fBHRTnJGk0lR7pQTJacEtaXibWUSS4deNRsELhaQOHQAGDCrXwoRnjGFSkoL6Q>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/11f049c1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C03125F7 at D66F897A.0672D26800000000.gif
Type: image/gif
Size: 1848711 bytes
Desc: C03125F7 at D66F897A.0672D26800000000.gif
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250923/11f049c1/C03125F7D66F897A.0672D26800000000-0001.gif>

From mstrauss at openjdk.org  Tue Sep 23 21:03:08 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 23 Sep 2025 21:03:08 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <9VK02l6Xn-LyfF7_g5y_5CUF2mJw0Btu7B8EQZcHcI8=.3a31c47c-55a0-44e3-ae50-c769190f1ee2@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
 <PBeITyUBQBOYrOCrDoni5PBozKWgrnQI8TFecxUQAgU=.a8751e07-c9d6-4d63-a3b0-53c86c211926@github.com>
 <AgHamgiB66How1AqrOm4mpvUYt30pzoJGFvOrqa2W14=.f6a4d67b-14bc-4c2e-a156-65bde1768a03@github.com>
 <9VK02l6Xn-LyfF7_g5y_5CUF2mJw0Btu7B8EQZcHcI8=.3a31c47c-55a0-44e3-ae50-c769190f1ee2@github.com>
Message-ID: <Jc3kDpjOh2wMO0Cgphas4f-SrBXcFFUGHYPOg3SnUXQ=.9584e053-8fd2-4ae2-adf2-041916f6f4f7@github.com>

On Tue, 23 Sep 2025 18:04:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > So the last column of the last line would be a better choice than [0,0].
> 
> Right, the general idea is to show the correct information to the user. It can either be addressed this as a part of this PR or a follow up.

This would have to be another PR, because it's preexisting and unrelated to this bug.

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3325536856

From arapte at openjdk.org  Tue Sep 23 21:13:48 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 23 Sep 2025 21:13:48 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9
Message-ID: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>

**Issue**:
Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.

Both these methods are removed in Gradle 9.0.0.
Hence they should be replaced with appropriate APIs.
Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec

**Fix**:
Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
There are two different scenarios where we use the above two APIs.
- Gradle files
- Groovy class files
=> In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.

1. Gradle file
    - The calls are simply replaced as,
        * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
        * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
2. For Groovy classes
    - `ExecOperations` needs to be **injected** using `@Inject` tag
    1. `NativeCompileTask` class
        - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
        - The child classes of `NativeCompileTask`, use this `execCompile()` method.
    2. Other classes are not related to each other. They independently execute the respective action.

**Verification**:
1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
2. No Gradle 9.0.0 specific warning is seen in build log
4. Build/all tasks complete successfully.

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

Commit messages:
 - replace project.exec and project.javaexec

Changes: https://git.openjdk.org/jfx/pull/1918/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360586
  Stats: 250 lines in 13 files changed: 132 ins; 1 del; 117 mod
  Patch: https://git.openjdk.org/jfx/pull/1918.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1918/head:pull/1918

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

From kcr at openjdk.org  Wed Sep 24 00:20:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Sep 2025 00:20:16 GMT
Subject: [jfx25u] RFR: Merge jfx:jfx25
Message-ID: <bH63q-r4E5E5qAyUhVRL591GkbZN0OvyT_P-9M9fdVQ=.b022ab90-3798-42da-b31e-4edce56af9bb@github.com>

Clean merge from `jfx:jfx25` into `master`.

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

Commit messages:
 - Merge remote-tracking branch 'jfx/jfx25' into merge-jfx-jfx25-to-master-2025-09-23
 - 8365515: Create release notes for JavaFX 25

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx25u/pull/19/files
  Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx25u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/19/head:pull/19

PR: https://git.openjdk.org/jfx25u/pull/19

From kcr at openjdk.org  Wed Sep 24 00:24:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Sep 2025 00:24:51 GMT
Subject: [jfx25u] Integrated: Merge jfx:jfx25
In-Reply-To: <bH63q-r4E5E5qAyUhVRL591GkbZN0OvyT_P-9M9fdVQ=.b022ab90-3798-42da-b31e-4edce56af9bb@github.com>
References: <bH63q-r4E5E5qAyUhVRL591GkbZN0OvyT_P-9M9fdVQ=.b022ab90-3798-42da-b31e-4edce56af9bb@github.com>
Message-ID: <EzK-e9bGAXzbXKH-HN5U8NmuVHP5_Zc_cPbh66BN320=.d579fa1b-fa40-4b6a-88ad-9aeaa99bb4a4@github.com>

On Wed, 24 Sep 2025 00:15:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge from `jfx:jfx25` into `master`.

This pull request has now been integrated.

Changeset: 1ebaeba8
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/1ebaeba84d143d31e857e8ee41d614cd135492c7
Stats:     150 lines in 1 file changed: 150 ins; 0 del; 0 mod

Merge

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

PR: https://git.openjdk.org/jfx25u/pull/19

From arapte at openjdk.org  Wed Sep 24 03:22:16 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 24 Sep 2025 03:22:16 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
Message-ID: <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>

> **Issue**:
> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
> 
> Both these methods are removed in Gradle 9.0.0.
> Hence they should be replaced with appropriate APIs.
> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
> 
> **Fix**:
> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
> There are two different scenarios where we use the above two APIs.
> - Gradle files
> - Groovy class files
> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
> 
> 1. Gradle file
>     - The calls are simply replaced as,
>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
> 2. For Groovy classes
>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>     1. `NativeCompileTask` class
>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>     2. Other classes are not related to each other. They independently execute the respective action.
> 
> **Verification**:
> 1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
> 2. No Gradle 9.0.0 specific warning is seen in build log
> 4. Build/all tasks complete successfully.

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

 - Merge branch 'master' into gradle-900-warnings
 - replace project.exec and project.javaexec

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1918/files
  - new: https://git.openjdk.org/jfx/pull/1918/files/37c11744..14d07fa9

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

  Stats: 572 lines in 31 files changed: 463 ins; 39 del; 70 mod
  Patch: https://git.openjdk.org/jfx/pull/1918.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1918/head:pull/1918

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

From kcr at openjdk.org  Wed Sep 24 12:11:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Sep 2025 12:11:05 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
Message-ID: <q4YIhNHtt7yYrly6YGzNl6-GqWzhFgWjGBnwA3lxd5g=.d96bf033-9f7b-4fe2-b8b1-c849ca42b293@github.com>

On Wed, 24 Sep 2025 03:22:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> **Issue**:
>> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
>> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
>> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
>> 
>> Both these methods are removed in Gradle 9.0.0.
>> Hence they should be replaced with appropriate APIs.
>> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
>> 
>> **Fix**:
>> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
>> There are two different scenarios where we use the above two APIs.
>> - Gradle files
>> - Groovy class files
>> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
>> 
>> 1. Gradle file
>>     - The calls are simply replaced as,
>>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
>> 2. For Groovy classes
>>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>>     1. `NativeCompileTask` class
>>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>>     2. Other classes are not related to each other. They independently execute the respective action.
>> 
>> **Verification**:
>> 1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
>> 2. No Gradle 9.0.0 specific warning is seen in build log
>> 4. Build/all tasks complete successfully.
>
> Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into gradle-900-warnings
>  - replace project.exec and project.javaexec

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1918#issuecomment-3328104282

From arapte at openjdk.org  Wed Sep 24 12:46:10 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 24 Sep 2025 12:46:10 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v7]
In-Reply-To: <jIIhr-XoTnvWshJ9040n4J-qdd3Nesns8pL08u8hlec=.30a10d04-c5a5-44b4-99ff-431ea8f3d3b1@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <jIIhr-XoTnvWshJ9040n4J-qdd3Nesns8pL08u8hlec=.30a10d04-c5a5-44b4-99ff-431ea8f3d3b1@github.com>
Message-ID: <kw6YNyMihw38H-YOUnZGVMLagf_kP_wcsWFYnCVBDh4=.7aed743e-faac-4fda-9a7c-8a0aff709c7c@github.com>

On Wed, 17 Sep 2025 19:55:26 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 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
>  - Merge branch 'master' into 8353599.menu.factory
>  - Merge branch 'master' into 8353599.menu.factory
>  - Merge branch 'master' into 8353599.menu.factory
>  - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
>  - 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
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/1a67c5b4...2e8848ef

With this change, For a same tab the graphic in TabHeader and graphic in overflow menu can be different.
Here is a screenshot from modified version of the sample program.
<img width="308" height="364" alt="Screenshot 2025-09-24 at 18 04 50" src="https://github.com/user-attachments/assets/6494aca1-06ac-4aaf-a405-f6e55f5823ae" />

Of course it is in programmer's control.
But, can we fix on a behavior that if a graphic is set on a tab, then the same graphic would be used in overflow menu and a graphic from menuGraphicFactory will be neglected ?

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

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

From dlemmermann at gmail.com  Wed Sep 24 14:00:22 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 24 Sep 2025 16:00:22 +0200
Subject: Validation Support
Message-ID: <FA3FFA2A-889D-4684-A602-0C117CE42879@gmail.com>

Hi,

I was just wondering if any thought has been put into providing a standard approach to validating input? Something like ValidatorFX for example [1]? There have been attempts at solving this in ControlsFX but that one was too heavily bound to the actual controls while ValidatorFX works on anything that is observable. I have been using it now for several years in our CRM desktop application and I feel like it is striking a perfect balance between being flexible and easy to use.

Small / incomplete example:

	TextField userTextField = new TextField();

	Validator validator = new Validator();
        validator.createCheck()
          .dependsOn("username", userTextField.textProperty())
          .withMethod(c -> {
	            String userName = c.get("username");
        	    if (!userName.toLowerCase().equals(userName)) {
             		 c.error("Please use only lowercase letters.");
            		}
          	})
          .decorates(userTextField)
          .immediate();

I know that one can easily say ?just use the library? but I think that not everybody will find it and it also is nice to have a standard way of doing things.

Dirk

[1] https://github.com/effad/ValidatorFX

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250924/f9bf9815/attachment.htm>

From mstrauss at openjdk.org  Wed Sep 24 15:07:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 24 Sep 2025 15:07:24 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v8]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <6eAQZta1nqYsTHw4rboFIfU_C-wAfACPzJK_qPLEkFY=.5d7d9068-5a0c-4d23-8d2c-a38b53efad2e@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)

Michael Strau? 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 11 additional commits since the last revision:

 - update cssref.html
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - whitespace, add final modifier
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Refactor context awareness
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Clarify and test handling of text case
 - documentation
 - Replace context awareness flags with EnumSet
 - ... and 1 more: https://git.openjdk.org/jfx/compare/03503752...d15fa713

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/c6ad3e32..d15fa713

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=06-07

  Stats: 148014 lines in 1025 files changed: 80303 ins; 26731 del; 40980 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From angorya at openjdk.org  Wed Sep 24 15:25:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Sep 2025 15:25:34 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v7]
In-Reply-To: <kw6YNyMihw38H-YOUnZGVMLagf_kP_wcsWFYnCVBDh4=.7aed743e-faac-4fda-9a7c-8a0aff709c7c@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
 <jIIhr-XoTnvWshJ9040n4J-qdd3Nesns8pL08u8hlec=.30a10d04-c5a5-44b4-99ff-431ea8f3d3b1@github.com>
 <kw6YNyMihw38H-YOUnZGVMLagf_kP_wcsWFYnCVBDh4=.7aed743e-faac-4fda-9a7c-8a0aff709c7c@github.com>
Message-ID: <fhQV6cRu1GJGp1aIGkskXQQjqQwN6lWfIR2khmia-TY=.2a365b7b-642e-4801-8afd-80005756c7ee@github.com>

On Wed, 24 Sep 2025 12:43:19 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> But, can we fix on a behavior that if a graphic is set on a tab, then the same graphic would be used in overflow menu and a graphic from menuGraphicFactory will be neglected ?

Good question!

We can't, if the graphic set on a tab is some sort of a custom `Node` and not the usual `ImageView` or `Label`.  In this case, we can't easily clone that custom graphic such that it appears in the tab **and** in the overflow menu.

Ideally, the solution would be to replace setting the graphic on a tab with setting a Supplier<Node>.  This way the graphic can be supplied multiple times as needed, but it would be a breaking change and something that is not needed in 99.9% of the cases.

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

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

From arapte at openjdk.org  Wed Sep 24 15:53:32 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 24 Sep 2025 15:53:32 GMT
Subject: RFR: 8367995: [TestBug] Rename ErrorLoggingUtiltity
In-Reply-To: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
References: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
Message-ID: <3O_5Q7fS6T6bwZoPvGmtNR5R5E-8F9fv2KV7zhxfMhM=.14c8a9d1-f376-4919-ac1e-c5383ff94877@github.com>

On Thu, 18 Sep 2025 15:50:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The follow-up to #1897: fixing spelling of `ErrorLoggingUtiltity`.

LGTM.
Majority of change is typo correction, with a few import statements and copyright year change.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1912#pullrequestreview-3263591036

From mstrauss at openjdk.org  Wed Sep 24 18:00:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 24 Sep 2025 18:00:43 GMT
Subject: RFR: 8367995: [TestBug] Rename ErrorLoggingUtiltity
In-Reply-To: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
References: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
Message-ID: <PvCZigHSSiwvwFTY4h95RY09xFEBWYJE-UILwDsXKeI=.e1ddcca6-6bb6-4ac9-a4a0-d30d9598bad8@github.com>

On Thu, 18 Sep 2025 15:50:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The follow-up to #1897: fixing spelling of `ErrorLoggingUtiltity`.

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1912#pullrequestreview-3264038244

From angorya at openjdk.org  Wed Sep 24 18:00:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Sep 2025 18:00:43 GMT
Subject: RFR: 8367995: [TestBug] Rename ErrorLoggingUtiltity
In-Reply-To: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
References: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
Message-ID: <c7gtNjqhGvuO5CN1dm4M250vCp26Sh4JLkMBrs0dEcg=.b0684efc-3901-4340-9282-e0f1fec4f9e8@github.com>

On Thu, 18 Sep 2025 15:50:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The follow-up to #1897: fixing spelling of `ErrorLoggingUtiltity`.

thank you all for reviewing!

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

PR Comment: https://git.openjdk.org/jfx/pull/1912#issuecomment-3330051002

From angorya at openjdk.org  Wed Sep 24 18:00:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Sep 2025 18:00:44 GMT
Subject: Integrated: 8367995: [TestBug] Rename ErrorLoggingUtiltity
In-Reply-To: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
References: <zp3Di975Pc7gWVVeH8xQXFX_RorWrT898aw7uGsbD0M=.b2b26cc3-ea4b-4756-b4ec-d64ed9e28ec5@github.com>
Message-ID: <sv76nYjFwd4PLYzLmoquxckFyJcGog5PH6DOKOO-1Z0=.fc33ce5d-46aa-476d-aefe-ed294037af76@github.com>

On Thu, 18 Sep 2025 15:50:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The follow-up to #1897: fixing spelling of `ErrorLoggingUtiltity`.

This pull request has now been integrated.

Changeset: cca1703f
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/cca1703f49585843fc82517a828ed59b68b76ab8
Stats:     729 lines in 13 files changed: 71 ins; 71 del; 587 mod

8367995: [TestBug] Rename ErrorLoggingUtiltity

Reviewed-by: arapte, mstrauss

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

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

From mstrauss at openjdk.org  Wed Sep 24 18:04:31 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 24 Sep 2025 18:04:31 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap
Message-ID: <T0umPuTFXzKCWq2B7YcSWx44vHWfLDg-W5ICBFkISRE=.bd4ab8f7-a065-4e37-9703-e59bea369458@github.com>

Implementation of bulk change notifications for ObservableSet and ObservableMap.

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

Commit messages:
 - add tests, documentation
 - Implementation of bulk change listeners for ObservableSet and ObservableMap

Changes: https://git.openjdk.org/jfx/pull/1885/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1885&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367439
  Stats: 1193 lines in 13 files changed: 1017 ins; 114 del; 62 mod
  Patch: https://git.openjdk.org/jfx/pull/1885.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1885/head:pull/1885

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

From angorya at openjdk.org  Wed Sep 24 18:04:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Sep 2025 18:04:34 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap
In-Reply-To: <T0umPuTFXzKCWq2B7YcSWx44vHWfLDg-W5ICBFkISRE=.bd4ab8f7-a065-4e37-9703-e59bea369458@github.com>
References: <T0umPuTFXzKCWq2B7YcSWx44vHWfLDg-W5ICBFkISRE=.bd4ab8f7-a065-4e37-9703-e59bea369458@github.com>
Message-ID: <nwcUy0FLr1vOLvZnFZXbOHhhmDLaVcKYcas54CZJd7A=.f7248788-eb97-4dc1-9411-bfb875d44c9b@github.com>

On Sun, 7 Sep 2025 00:12:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of bulk change notifications for ObservableSet and ObservableMap.

modules/javafx.base/src/test/java/test/javafx/collections/ObservableMapTest.java line 196:

> 194: 
> 195:         observer.assertMultipleCalls(call("one", "1", "2"), call("two", "2", "3"));
> 196:     }

>From the description:


The implementation is fully backwards-compatible for listeners that
are unaware of the new API. If the next() method is not called, then
all subsequent changes are delivered as usual by repeated listener
invocations.

If a listener only fetches some changes of a bulk operation (but stops
halfway through the operation), the remaining changes will also be
delivered with repeated listener invocations.


1. should this be included in javadoc?
2. could we add a test for this scenario?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2330590388

From notzed at gmail.com  Thu Sep 25 00:48:48 2025
From: notzed at gmail.com (Michael Zucchi)
Date: Thu, 25 Sep 2025 10:18:48 +0930
Subject: JDK-8210547[linux] Uncontrolled framerate, general frame
 sync/over-calculating animations
In-Reply-To: <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
References: <e66e87f7-1eca-44ee-8189-2dce95cfbe0b@gmail.com>
 <ee44ba34-b227-4d1d-b648-1886a642fdc4@oracle.com>
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
Message-ID: <17545cf2-7cd6-47b1-8608-48bba8c16d1c@gmail.com>

Hi Kevin,

On 23/9/25 01:02, Kevin Rushforth wrote:
> Hi Michael,
>
> Welcome to the openjfx-dev list. We've not ever been able to reproduce 
> this on any of our systems. It seems likely that it is specific to 
> certain graphics drivers. We do all our testing on Ubuntu Linux and 
> Oracle Linux (which is based on RHEL), so it's also possible we are 
> testing with different drivers even for the same card.
>

Thanks, and I've subscribed to the dev list.? It just seemed to be full 
of patch discussion so I wasn't sure where to post.

Indeed I saw on the bug nobody could recreate it.? Weird.? I tried 
Oracle Linux 10 on my laptop but I couldn't get it to load the 
modesetting driver and boot (incl the official amd driver).? With ubuntu 
25 vanilla i'm getting the same unthrottled framerate as on my other 
systems.? I was hoping this wasn't the case so I could see why you 
weren't seeing this, so? I'll try the other desktops in-case it's 
related to the compositor but it's going to take a while as i'm using a 
usb stick and ubuntu installation seems very disk heavy in ways every 
other linux isn't.

I've attached a standalone example - it runs about 2000fps on one system 
when it's down to 1 window.? It's intentionally updating each pulse 
ignoring the 'frac' value so the pulse timing can be visualised.

I don't know if it's useful but this is sample output from quantum.debug:

QT.postPulse#(95891966861546): DROP : TAPN
QT.endPulse: 95891966882376
QT.vsyncHint: postPulse: 95891967385262
QT.postPulse@(95891967391984): TAPN
QT.endPulse: 95891967429776
QT.vsyncHint: postPulse: 95891968031510
QT.postPulse@(95891968039475): TAPN
QT.endPulse: 95891968072438
QT.vsyncHint: postPulse: 95891968663842
QT.postPulse@(95891968671827): TAPN
QT.endPulse: 95891968696373

This last basic sequence repeats a dozen or so times times until a DROP 
: TAPN again

Note that each postPulse() is about 650uS apart.


> If you have a reliable patch for the bug, you can submit a PR although 
> we will need to find a way to test it. See the CONTRIBUTING [1] 
> guidelines for what you will need to do in order to contribute.
>

I spent a frustrating hour or so trying to log into an oracle account I 
forgot I had, then creating a new one which I also can't log into ("A 
federated user can't perform local authentication.") so I can't sign the 
OCA for now (if it ever gets to that point).

I looked more at the latest code (without the vsync patch).

Commenting out makeCurrent(null) in ES2SwapChain.present() throttles the 
pulse but only if there is a single window (i.e. because the context 
never changes).? Perhaps this is a driver difference, and causes 
glxswapbuffers not to throttle even with double buffering on the 
rendering context.? makeContext is quite expensive (a few ms), so i'm 
surprised it is called every render pass (apart from the obvious of 
being easier to implement with a single render thread). Adding a 
glFinish() immediately after swapbuffers almost works but it halves the 
framerate when too many windows (>2) are active because it's performed 
per-window and not per-pulse.

Secondly, tracing PaintCollector.done() calls toolkit.vsyncHint() which 
calls postPulse() whose logic will always fire a new pulse when an 
animation is active (i.e. the Transition in the example). Is this really 
the expected behaviour here???vsyncHint() seems to be to perform a vsync 
not to fire another pulse.? ?Just commenting out vsyncHint() fixes the 
poor throttling but then it runs quite jittery due to timing via 
gdk_thread_timeout.

I added some time measurement to ES2SWwapChain.present() with a single 
window and it confirms that this is where the throttling or not occurs - 
with makeCurrent(null) removed 2 frames are presented very quickly then 
swapBuffers() blocks to match the display (and also means rendering is 2 
frames ahead).? With it added in it just runs asynchronously and returns 
very quickly.? I was hoping to confirm against a 'working' platform but 
alas so far.

TBH the throttling is important but I was also curious about addressing 
the jitteriness due to using gdk_thread_timeout, it seems vsyncHint() is 
meant for that but there doesn't seem to be any linkage between that and 
the pulse timing esp since the 'hint' isn't vsync-synced, so it just 
ends up firing another pulse immediately or pausing the timer if no 
animation is active.

I'm still thinking of fixes, perhaps a more accurate pulse timer is 
enough (and basically ignore vsyncHint) but it will have to be platform 
specific.? I will have to study the other backends a bit more first as well.

Are there plans for a vulkan backend?? That might solve/move the 
problem.? I've seen in mentioned in the past but I can't find anything 
on the web about anything concrete.

Regards,
 ?Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250925/c9fc81d5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: throttle.java
Type: text/x-java
Size: 2151 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250925/c9fc81d5/throttle-0001.java>

From arapte at openjdk.org  Thu Sep 25 12:36:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 25 Sep 2025 12:36:47 GMT
Subject: RFR: 8368631: Avoid updating disposed MTLTexture
Message-ID: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>

Issue: 
Calling MTLTexture.update() method on a disposed MTLTexture object would cause a crash.
The root cause of this behavior is [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629).

Fix:
Avoid MTLTexture.update() if texture is disposed.
The crash should be fixed now and the root cause will be followed up using [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)

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

Commit messages:
 - avoid MTLTexture.update if disposed

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

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

From kcr at openjdk.org  Thu Sep 25 12:42:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Sep 2025 12:42:11 GMT
Subject: RFR: 8368631: Avoid updating disposed MTLTexture
In-Reply-To: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
References: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
Message-ID: <6fffGnR3pYT39mbJ-0QhppFYJLWFtiGmEoM86pheOh0=.4e627622-ab56-45bb-a483-00e22c625d21@github.com>

On Thu, 25 Sep 2025 12:31:01 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> Calling MTLTexture.update() method on a disposed MTLTexture object would cause a crash.
> The root cause of this behavior is [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629).
> 
> Fix:
> Avoid MTLTexture.update() if texture is disposed.
> The crash should be fixed now and the root cause will be followed up using [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)

Reviewers: @kevinrushforth @aghaisas

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

PR Comment: https://git.openjdk.org/jfx/pull/1919#issuecomment-3333741476

From kcr at openjdk.org  Thu Sep 25 15:08:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Sep 2025 15:08:16 GMT
Subject: RFR: 8368631: Avoid updating disposed MTLTexture
In-Reply-To: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
References: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
Message-ID: <f97e5Pb0SebQvaS6OIKKdRHFsJPQ00rLTrv_S1E-FoM=.870fad02-e8c6-45f4-8c27-d810b27eb03b@github.com>

On Thu, 25 Sep 2025 12:31:01 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> Calling MTLTexture.update() method on a disposed MTLTexture object would cause a crash.
> The root cause of this behavior is [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629).
> 
> Fix:
> Avoid MTLTexture.update() if texture is disposed.
> The crash should be fixed now and the root cause will be followed up using [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1919#pullrequestreview-3268252551

From aghaisas at openjdk.org  Thu Sep 25 15:28:03 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 25 Sep 2025 15:28:03 GMT
Subject: RFR: 8368631: Avoid updating disposed MTLTexture
In-Reply-To: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
References: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
Message-ID: <e3hwuI-SFH5DrzWnIBPxgcT4UVXamSSVoCV85nKEHz8=.ef0159a7-4bb7-41bc-b528-820245c3c82c@github.com>

On Thu, 25 Sep 2025 12:31:01 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> Calling MTLTexture.update() method on a disposed MTLTexture object would cause a crash.
> The root cause of this behavior is [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629).
> 
> Fix:
> Avoid MTLTexture.update() if texture is disposed.
> The crash should be fixed now and the root cause will be followed up using [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)

Looks good.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1919#pullrequestreview-3268332246

From kcr at openjdk.org  Thu Sep 25 21:50:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Sep 2025 21:50:31 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
Message-ID: <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>

On Wed, 24 Sep 2025 03:22:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> **Issue**:
>> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
>> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
>> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
>> 
>> Both these methods are removed in Gradle 9.0.0.
>> Hence they should be replaced with appropriate APIs.
>> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
>> 
>> **Fix**:
>> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
>> There are two different scenarios where we use the above two APIs.
>> - Gradle files
>> - Groovy class files
>> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
>> 
>> 1. Gradle file
>>     - The calls are simply replaced as,
>>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
>> 2. For Groovy classes
>>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>>     1. `NativeCompileTask` class
>>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>>     2. Other classes are not related to each other. They independently execute the respective action.
>> 
>> **Verification**:
>> 1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
>> 2. No Gradle 9.0.0 specific warning is seen in build log
>> 4. Build/all tasks complete successfully.
>
> Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into gradle-900-warnings
>  - replace project.exec and project.javaexec

I left a suggestion for eliminating the type of the closure argument. For example, I think you can use:


    execOps.exec { spec ->


This applies to all of the exec calls in the various gradle and groovy files you had to change). If you prefer to keep the explicit type, it's OK, too. I just think it might be cleaner without it.

Also, it looks like you missed one or more warnings. I still see this in the log:


2025-09-24T03:23:05.2477610Z Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
2025-09-24T03:23:05.2477970Z 
2025-09-24T03:23:05.2478350Z You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
2025-09-24T03:23:05.2478790Z 
2025-09-24T03:23:05.2479320Z For more on this, please refer to https://docs.gradle.org/8.14.2/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
2025-09-24T03:23:05.2479870Z 
2025-09-24T03:23:05.2480020Z BUILD SUCCESSFUL in 3m 32s


See, for example:

https://github.com/arapte/jfx/actions/runs/17965277238/job/51102558023

build.gradle line 888:

> 886:                         pkgdir.mkdirs()
> 887:                         def execOps = project.services.get(ExecOperations)
> 888:                         execOps.exec { ExecSpec spec ->

Suggestion:

                        execOps.exec { spec ->


We generally don't include the type of a closure argument, unless it's ambiguous (which I don't think it is here).

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

PR Review: https://git.openjdk.org/jfx/pull/1918#pullrequestreview-3269537051
PR Review Comment: https://git.openjdk.org/jfx/pull/1918#discussion_r2380379516

From kcr at openjdk.org  Thu Sep 25 22:25:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Sep 2025 22:25:00 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
 <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>
Message-ID: <CfuL6-McpkpSR1khHHhTZncd0KU1O5SfehoSiAQe6zo=.60eb06df-c90a-474f-b7f4-f0d79c99be95@github.com>

On Thu, 25 Sep 2025 21:47:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Also, it looks like you missed one or more warnings. I still see this in the log:
> ...

Although... if I build using gradle 8.14.2 with `--gradle-warning all` I get a list of gradle 10 deprecation warnings, but no gradle 9 deprecation warnings.  And building with gradle 9 produces no error (just the same gradle 10 warnings), so this might just be a mistake in gradle 8.14.2 warning reporting.

So this looks fine to me. I'll do more testing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1918#issuecomment-3336115250

From hmeda at openjdk.org  Fri Sep 26 07:04:36 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Fri, 26 Sep 2025 07:04:36 GMT
Subject: RFR: 8368691: Update libxml2 to 2.14.6
Message-ID: <lDyFkFQETaIYmgzqp86L-Ou9r7rPISslGI9SXzoqOpQ=.5f06a6ca-456e-48f4-8d42-9b0f65027e4f@github.com>

Updated libxml2 to v2.14.6. Verified build on all platforms. No issue seen.

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

Commit messages:
 - version update
 - whitespace correction
 - configure libxml on windows
 - configure libxml on linux
 - update libxml to v2.14.6

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

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

From dlemmermann at gmail.com  Fri Sep 26 09:26:35 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Fri, 26 Sep 2025 11:26:35 +0200
Subject: EA release with TabPane layout fix?
Message-ID: <349B8386-476E-48E9-BD42-3081F5B672A1@gmail.com>

Hi guys,

Are there any short-term plans for releasing an early access version (25 or 26) that will include the fix for the TabPane layout issue?

https://bugs.openjdk.org/browse/JDK-8367602?

Dirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/de4b2d1d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-favicon-hires.png
Type: image/png
Size: 1085 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/de4b2d1d/jira-favicon-hires-0001.png>

From arapte at openjdk.org  Fri Sep 26 10:29:44 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 26 Sep 2025 10:29:44 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v3]
In-Reply-To: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
Message-ID: <dTVggef8CHpSV00FhFASiaOFhDuyyrY_C-rDnKztvww=.1e96c04d-a411-4fee-a1f2-cf6883006368@github.com>

> **Issue**:
> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
> 
> Both these methods are removed in Gradle 9.0.0.
> Hence they should be replaced with appropriate APIs.
> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
> 
> **Fix**:
> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
> There are two different scenarios where we use the above two APIs.
> - Gradle files
> - Groovy class files
> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
> 
> 1. Gradle file
>     - The calls are simply replaced as,
>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
> 2. For Groovy classes
>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>     1. `NativeCompileTask` class
>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>     2. Other classes are not related to each other. They independently execute the respective action.
> 
> **Verification**:
> 1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
> 2. No Gradle 9.0.0 specific warning is seen in build log
> 4. Build/all tasks complete successfully.

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

  rm ExecSpec from closure

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1918/files
  - new: https://git.openjdk.org/jfx/pull/1918/files/14d07fa9..73ecdeb9

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

  Stats: 81 lines in 12 files changed: 0 ins; 12 del; 69 mod
  Patch: https://git.openjdk.org/jfx/pull/1918.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1918/head:pull/1918

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

From arapte at openjdk.org  Fri Sep 26 11:09:15 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 26 Sep 2025 11:09:15 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
 <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>
Message-ID: <yQfqYsiV2T50rwU1Ys9YiSCeUf39X_yV2iRtqa0lEgE=.5a37efb9-a046-4244-b8b3-097eefb68d04@github.com>

On Thu, 25 Sep 2025 21:35:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into gradle-900-warnings
>>  - replace project.exec and project.javaexec
>
> build.gradle line 888:
> 
>> 886:                         pkgdir.mkdirs()
>> 887:                         def execOps = project.services.get(ExecOperations)
>> 888:                         execOps.exec { ExecSpec spec ->
> 
> Suggestion:
> 
>                         execOps.exec { spec ->
> 
> 
> We generally don't include the type of a closure argument, unless it's ambiguous (which I don't think it is here).

Thank you, removed the type from all such instances.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1918#discussion_r2382016497

From arapte at openjdk.org  Fri Sep 26 11:12:15 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 26 Sep 2025 11:12:15 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v2]
In-Reply-To: <CfuL6-McpkpSR1khHHhTZncd0KU1O5SfehoSiAQe6zo=.60eb06df-c90a-474f-b7f4-f0d79c99be95@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <ZoYscK97l0VffnRS46REHbGE0bmDQrGVwrR0RAIZVvE=.4da57f35-f310-4957-8e55-c3430f3a0fb9@github.com>
 <7SpOCglmsBU2TazE9h29kNWBHwdoUndNiptvfgc8NvM=.5533ab28-d52a-4052-9b10-a3f87d18814d@github.com>
 <CfuL6-McpkpSR1khHHhTZncd0KU1O5SfehoSiAQe6zo=.60eb06df-c90a-474f-b7f4-f0d79c99be95@github.com>
Message-ID: <plXeO8QmnKbEEFI-Z-jLfsmovPz9ZTfPzWZQRGpc648=.b1efb616-d239-49ad-8003-9ddc8e71e832@github.com>

On Thu, 25 Sep 2025 22:22:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Although... if I build using gradle 8.14.2 with `--gradle-warning all` I get a list of gradle 10 deprecation warnings, but no gradle 9 deprecation warnings. And building with gradle 9 produces no error (just the same gradle 10 warnings), so this might just be a mistake in gradle 8.14.2 warning reporting.
> 
> So this looks fine to me. I'll do more testing.

Yes Kevin, I also observed the same behavior. It seems safe as build completes successfully with Gradle 9

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

PR Comment: https://git.openjdk.org/jfx/pull/1918#issuecomment-3338172626

From kcr at openjdk.org  Fri Sep 26 11:26:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Sep 2025 11:26:28 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v3]
In-Reply-To: <dTVggef8CHpSV00FhFASiaOFhDuyyrY_C-rDnKztvww=.1e96c04d-a411-4fee-a1f2-cf6883006368@github.com>
References: <mVAXnqDhZdBXzqkARMHJeb2LXabyUZVrtWsbe1h527g=.4960ac58-426f-4574-8383-5664b2397996@github.com>
 <dTVggef8CHpSV00FhFASiaOFhDuyyrY_C-rDnKztvww=.1e96c04d-a411-4fee-a1f2-cf6883006368@github.com>
Message-ID: <qw74u4tZutjO0TQGvlucrkAxnFJvZ92oDKPTg4D7aqE=.4e88a0fe-1723-43f7-bdf5-febe0b5a973f@github.com>

On Fri, 26 Sep 2025 10:29:44 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> **Issue**:
>> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
>> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
>> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
>> 
>> Both these methods are removed in Gradle 9.0.0.
>> Hence they should be replaced with appropriate APIs.
>> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
>> 
>> **Fix**:
>> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
>> There are two different scenarios where we use the above two APIs.
>> - Gradle files
>> - Groovy class files
>> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
>> 
>> 1. Gradle file
>>     - The calls are simply replaced as,
>>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
>> 2. For Groovy classes
>>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>>     1. `NativeCompileTask` class
>>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>>     2. Other classes are not related to each other. They independently execute the respective action.
>> 
>> **Verification**:
>> 1. Run all gradle tasks with **?warning-mode all** option, with gradle 8.14.2 
>> 2. No Gradle 9.0.0 specific warning is seen in build log
>> 4. Build/all tasks complete successfully.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rm ExecSpec from closure

Looks good. Testing is green.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1918#pullrequestreview-3271770531

From kcr at openjdk.org  Fri Sep 26 12:07:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Sep 2025 12:07:05 GMT
Subject: RFR: 8368691: Update libxml2 to 2.14.6
In-Reply-To: <lDyFkFQETaIYmgzqp86L-Ou9r7rPISslGI9SXzoqOpQ=.5f06a6ca-456e-48f4-8d42-9b0f65027e4f@github.com>
References: <lDyFkFQETaIYmgzqp86L-Ou9r7rPISslGI9SXzoqOpQ=.5f06a6ca-456e-48f4-8d42-9b0f65027e4f@github.com>
Message-ID: <CWT1Vc7nav3CicChVaI7Yebn4m4eXGPtgNYoIV2dtWc=.6207bd82-55c7-47b2-a28e-31b1a7d391d3@github.com>

On Thu, 25 Sep 2025 12:37:48 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxml2 to v2.14.6. Verified build on all platforms. No issue seen.

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1920#issuecomment-3338353309

From lkostyra at openjdk.org  Fri Sep 26 13:30:37 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 26 Sep 2025 13:30:37 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v64]
In-Reply-To: <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@github.com>
Message-ID: <9N7xYPwBzeDve-zx83yeDFRe-wvkCL390bHru14Lvws=.7b4fe6ad-d654-4b3c-959e-b0761d116a4f@github.com>

On Sat, 20 Sep 2025 10:00:38 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.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8367898: Skip StageFocusTest on Linux"
>   
>   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.

Code in general looks good (minus one extraneous copyright header) however I did catch more failures when testing on our CI.

Mac machines fail these headful tests consistently (I suspect this is some sort of mistake like on Windows where decorations are not taken into account):

SizingTest > maxHeight(StageStyle) > maxHeight(StageStyle) [5] EXTENDED FAILED
    org.opentest4j.AssertionFailedError: Stage height should have been limited to max height ==> expected: <350.0> but was: <366.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.SizingTest.maxHeight(SizingTest.java:151)

SizingTest > minHeight(StageStyle) > minHeight(StageStyle) [5] EXTENDED FAILED
    org.opentest4j.AssertionFailedError: Stage height should have been limited to min height ==> expected: <500.0> but was: <516.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.SizingTest.minHeight(SizingTest.java:215)

SizingTest > maxSize(StageStyle) > maxSize(StageStyle) [5] EXTENDED FAILED
    org.opentest4j.AssertionFailedError: Stage height should have been limited to max height ==> expected: <350.0> but was: <366.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.SizingTest.maxSize(SizingTest.java:95)

SizingTest > minSize(StageStyle) > minSize(StageStyle) [1] DECORATED FAILED
    org.opentest4j.AssertionFailedError: Stage width should have been limited to min width ==> expected: <500.0> but was: <450.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.SizingTest.minSize(SizingTest.java:175)

SizingTest > minSize(StageStyle) > minSize(StageStyle) [2] UNDECORATED FAILED
    org.opentest4j.AssertionFailedError: Stage width should have been limited to min width ==> expected: <500.0> but was: <450.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.SizingTest.minSize(SizingTest.java:175)

SizingTest > minSize(StageStyle) > minSize(StageStyle) [3] TRANSPARENT FAILED
    org.opentest4j.AssertionFailedError: Stage width should have been limited to min width ==> expected: <500.0> but was: <450.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.SizingTest.minSize(SizingTest.java:175)

SizingTest > minSize(StageStyle) > minSize(StageStyle) [4] UTILITY FAILED
    org.opentest4j.AssertionFailedError: Stage width should have been limited to min width ==> expected: <500.0> but was: <450.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.SizingTest.minSize(SizingTest.java:175)

SizingTest > minSize(StageStyle) > minSize(StageStyle) [5] EXTENDED FAILED
    org.opentest4j.AssertionFailedError: Stage width should have been limited to min width ==> expected: <500.0> but was: <450.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.SizingTest.minSize(SizingTest.java:175)


On Ubuntu there also were two failures:

StageAttributesTest > testIconifiedStageBeforeShow(StageStyle) > testIconifiedStageBeforeShow(StageStyle) [2] UNDECORATED FAILED
    org.opentest4j.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(255,0,0,255)
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38)
        at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138)
        at app//test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:168)
        at app//test.robot.javafx.stage.StageAttributesTest.lambda$testIconifiedStageBeforeShow$1(StageAttributesTest.java:233)


IconifyTest > canIconifyDecoratedStage() FAILED
    org.opentest4j.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(0,215,0,255)
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38)
        at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138)
        at app//test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:168)
        at app//test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$8(IconifyTest.java:123)

These are existing tests that were un-skipped, but it seems there is still some issues with them.

tests/manual/stage/TestStage.java line 25:

> 23:  * questions.
> 24:  */
> 25: /*

This file ended up with two same copyright headers, I think we can only keep one :)

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3257725418
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2372137425

From kevin.rushforth at oracle.com  Fri Sep 26 14:10:49 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 26 Sep 2025 07:10:49 -0700
Subject: EA release with TabPane layout fix?
In-Reply-To: <349B8386-476E-48E9-BD42-3081F5B672A1@gmail.com>
References: <349B8386-476E-48E9-BD42-3081F5B672A1@gmail.com>
Message-ID: <2a475e04-d409-4486-b24a-689119eacb3b@oracle.com>

Hi Dirk,

The fix is in JavaFX 26 build 8, which is available on:

https://jdk.java.net/javafx26

If you need Maven bundles, Gluon can answer when JavaFX 26+8 (or later) 
will be available.

-- Kevin


On 9/26/2025 2:26 AM, Dirk Lemmermann wrote:
> Hi guys,
>
> Are there any short-term plans for releasing an early access version 
> (25 or 26) that will include the fix for the TabPane layout issue?
>
> Loading... <https://bugs.openjdk.org/browse/JDK-8367602>
> bugs.openjdk.org <https://bugs.openjdk.org/browse/JDK-8367602>
> 	jira-favicon-hires.png <https://bugs.openjdk.org/browse/JDK-8367602>
>
> <https://bugs.openjdk.org/browse/JDK-8367602>
>
>
> Dirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/6d665619/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-favicon-hires.png
Type: image/png
Size: 1085 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/6d665619/jira-favicon-hires-0001.png>

From mfox at openjdk.org  Fri Sep 26 14:31:03 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 26 Sep 2025 14:31:03 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v64]
In-Reply-To: <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@github.com>
Message-ID: <V8U5g6-VWHhDa-VzIqoIYVOQJApCl99OMcfPrA1aUAo=.9a3d6d1b-d06d-4a94-a078-35af434297e8@github.com>

On Sat, 20 Sep 2025 10:00:38 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.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8367898: Skip StageFocusTest on Linux"
>   
>   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.

I've already submitted PR #1870 to fix the sizing test failures on Mac and Windows. The problem is not with the tests. When the platform code enforces the min/max restrictions it has to send a notifySize event to ensure the window properties are updated correctly.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3338971001

From john.hendrikx at gmail.com  Fri Sep 26 16:03:09 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 26 Sep 2025 18:03:09 +0200
Subject: EA release with TabPane layout fix?
In-Reply-To: <2a475e04-d409-4486-b24a-689119eacb3b@oracle.com>
References: <349B8386-476E-48E9-BD42-3081F5B672A1@gmail.com>
 <2a475e04-d409-4486-b24a-689119eacb3b@oracle.com>
Message-ID: <db6f462e-bb13-4a1d-90ce-f22228455931@gmail.com>

Ah, I didn't know they were also available elsewhere, I only looked at
Maven Central (latest there is still ea+7 though).

--John

On 26/09/2025 16:10, Kevin Rushforth wrote:
> Hi Dirk,
>
> The fix is in JavaFX 26 build 8, which is available on:
>
> https://jdk.java.net/javafx26
>
> If you need Maven bundles, Gluon can answer when JavaFX 26+8 (or
> later) will be available.
>
> -- Kevin
>
>
> On 9/26/2025 2:26 AM, Dirk Lemmermann wrote:
>> Hi guys,
>>
>> Are there any short-term plans for releasing an early access version
>> (25 or 26) that will include the fix for the TabPane layout issue?
>>
>> Loading... <https://bugs.openjdk.org/browse/JDK-8367602>
>> bugs.openjdk.org <https://bugs.openjdk.org/browse/JDK-8367602>
>> 	jira-favicon-hires.png <https://bugs.openjdk.org/browse/JDK-8367602>
>>
>> <https://bugs.openjdk.org/browse/JDK-8367602>
>>
>>
>> Dirk
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/54f6c536/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-favicon-hires.png
Type: image/png
Size: 1085 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250926/54f6c536/jira-favicon-hires.png>

From dlemmermann at gmail.com  Fri Sep 26 16:57:02 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Fri, 26 Sep 2025 18:57:02 +0200
Subject: EA release with TabPane layout fix?
In-Reply-To: <2a475e04-d409-4486-b24a-689119eacb3b@oracle.com>
References: <349B8386-476E-48E9-BD42-3081F5B672A1@gmail.com>
 <2a475e04-d409-4486-b24a-689119eacb3b@oracle.com>
Message-ID: <0BC802BC-A58F-46FC-A3CB-B139CC3C74BA@gmail.com>

Thanks Kevin,

I will wait for Gluon then.

Dirk


> Am 26.09.2025 um 16:10 schrieb Kevin Rushforth <kevin.rushforth at oracle.com>:
> 
> Hi Dirk,
> 
> The fix is in JavaFX 26 build 8, which is available on:
> 
> https://jdk.java.net/javafx26
> 
> If you need Maven bundles, Gluon can answer when JavaFX 26+8 (or later) will be available.
> 
> -- Kevin
> 
> 
> On 9/26/2025 2:26 AM, Dirk Lemmermann wrote:
>> Hi guys,
>> 
>> Are there any short-term plans for releasing an early access version (25 or 26) that will include the fix for the TabPane layout issue?
>> 
>> https://bugs.openjdk.org/browse/JDK-8367602
>> 
>> Dirk
>> 
> 

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

From kcr at openjdk.org  Fri Sep 26 16:57:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Sep 2025 16:57:32 GMT
Subject: RFR: 8368691: Update libxml2 to 2.14.6
In-Reply-To: <lDyFkFQETaIYmgzqp86L-Ou9r7rPISslGI9SXzoqOpQ=.5f06a6ca-456e-48f4-8d42-9b0f65027e4f@github.com>
References: <lDyFkFQETaIYmgzqp86L-Ou9r7rPISslGI9SXzoqOpQ=.5f06a6ca-456e-48f4-8d42-9b0f65027e4f@github.com>
Message-ID: <IHopdXIauoRMXbDbs44OrqX5fRCX7fM9cz3P0VI9TJU=.8196f12b-dc06-49f0-96d3-d66f2092b465@github.com>

On Thu, 25 Sep 2025 12:37:48 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxml2 to v2.14.6. Verified build on all platforms. No issue seen.

The changes look good. Sanity test build is green.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1920#pullrequestreview-3273066865

From mstrauss at openjdk.org  Sat Sep 27 05:02:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 27 Sep 2025 05:02:46 GMT
Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong
 side
Message-ID: <FgoP-JrLHGHWC-uEjOdd0awhb4KllXmjiIodPDA8SIk=.505371ab-f871-419c-a3a6-27dad64a44a1@github.com>

When an extended stage is shown with RTL orientation (either using a RTL window + `Scene.nodeOrientation == INHERIT`, or using a LTR window and `Scene.nodeOrientation == RIGHT_TO_LEFT`), the default window buttons are placed on the wrong side of the window. This bug only manifests on Windows and Linux, both of which use `HeaderButtonOverlay` to render the default window buttons.

`HeaderButtonOverlay` is not a part of the scene graph, it is shown on top of the scene graph as an overlay (like the warning overlay that appears when entering full-screen mode). For [CSS-related reasons](https://github.com/openjdk/jfx/pull/1605#issuecomment-2967977276), the parent of an overlay is the scene root (but the scene root doesn't know that). This implementation detail can mess up the calculation of orientation flags and mirroring transforms in `Node`, as depending on the `NodeOrientation` of the root node, the code may mistakenly mirror (or not mirror) the orientation.

The solution I've come up with is as follows: the overlay node is marked with the `Node.INHERIT_ORIENTATION_FROM_SCENE` flag, which causes it to resolve its effective orientation against the scene only, and never against the root node. With this change, the effective orientation and mirroring transforms are computed correctly.

The easiest way to test this fix is with Monkey Tester -> Tools -> Stage Tester.

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

Commit messages:
 - fix node orientation of scene overlay

Changes: https://git.openjdk.org/jfx/pull/1921/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1921&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368021
  Stats: 130 lines in 6 files changed: 102 ins; 5 del; 23 mod
  Patch: https://git.openjdk.org/jfx/pull/1921.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1921/head:pull/1921

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

From duke at openjdk.org  Sat Sep 27 08:58:35 2025
From: duke at openjdk.org (duke)
Date: Sat, 27 Sep 2025 08:58:35 GMT
Subject: Withdrawn: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
Message-ID: <lsZlq6RCwtWjJE2ttW3LKATt-g0Gpzodyd3ZbChx5Y4=.f75f2264-7e34-481f-a9da-86c9449b2f79@github.com>

On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
> 
> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
> 
> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
> 
> The contract of `refresh()` is also a big vague, stating:
> 
> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
> necessary to populate the visual bounds of the control.
> In other words, this forces the XXX to update what it is showing to the user. 
> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
> 
> 
> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).

This pull request has been closed without being integrated.

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

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

From johan.vos at gluonhq.com  Sat Sep 27 09:55:19 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sat, 27 Sep 2025 11:55:19 +0200
Subject: Building OpenJFX using the OpenJDK build system
Message-ID: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>

Hi,

As part of my efforts to build OpenJFX using the OpenJDK build system, I
created a script that exactly does this. The script is used in the Github
Action in the repository https://github.com/openjdk-mobile/openjfx-build .
For questions about why this is done in the openjdk-mobile organisation on
github, see below.

The steps that are executed in the GhA are described in the README.md at
https://github.com/openjdk-mobile/openjfx-build .
Basically, this boils down to
1. clone latest openjdk (or openjdk/mobile)
2. clone latest openjfx
3. apply a small patch to the openjdk repository (so that it can deal with
--with-openjfx-modules)
4. run the gradle tasks to generate shaderclasses (to be removed)
5. configure and make the openjdk image.

We do have GhA scripts that can do the build on-demand, and they can be
modified to create daily/weekly/... builds. We do not recommend to use
these scripts for production. At least with Gluon, we do builds from a
Jenkins system where we have full control over the environment. This allows
us to use e.g. an ubuntu 24.04 system and deliver binaries that are working
on ubuntu 20.04, for example.
The value of the Github Actions, imho, is to easily detect an issue with
new code in either of the repositories.

An important thing is that this is using the very latest openjdk and
openjfx code. As I said before: it is not hard to create builds of OpenJFX
using the OpenJDK for a very specific version, using (very specific)
patches. The hard thing is to do this without requiring a huge maintenance
effort.

There are many todo's left, including:
* make it work on windows, ios and android
* include media and webkit
* generate shaders using the OpenJDK code-generate approach

This is an open effort, so everyone is welcome to contribute. But also, if
others want to use a different approach, I'm all fine with that.

- Johan

Q: Why is this in a repository that is part of the openjdk-mobile
initiative?
A: JavaFX is an optional, but crucial part when running Java applications
on mobile. Since on mobile, it is even more critical to use the correct
compilers/tools/settings/flags than it is on desktop, it is really
beneficial to use a single build system for all components that have native
code. Hence, while building OpenJFX using the OpenJDK build system is very
useful for desktop platforms, it is almost a requirement when building for
mobile platforms.
Note that currently, we only have scripts to build OpenJFX on OpenJDK for
linux and mac (hence not yet for mobile).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250927/a10f39e4/attachment-0001.htm>

From bourges.laurent at gmail.com  Sat Sep 27 10:29:30 2025
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 27 Sep 2025 12:29:30 +0200
Subject: Building OpenJFX using the OpenJDK build system
In-Reply-To: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>
References: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>
Message-ID: <CAKjRUT5qFxLbORSUR+zEr93-9HciGfCy=sk8qOpAUdiBdpmVMQ@mail.gmail.com>

Hi johan,

We are back to the great OpenJDK / JFX all-in-one package as it was the
case in jdk8 to 10 !

I love it,
Let's go forward now!

Cheers,
Laurent


Le sam. 27 sept. 2025, 11:56, Johan Vos <johan.vos at gluonhq.com> a ?crit :

> Hi,
>
> As part of my efforts to build OpenJFX using the OpenJDK build system, I
> created a script that exactly does this. The script is used in the Github
> Action in the repository https://github.com/openjdk-mobile/openjfx-build
> . For questions about why this is done in the openjdk-mobile organisation
> on github, see below.
>
> The steps that are executed in the GhA are described in the README.md at
> https://github.com/openjdk-mobile/openjfx-build .
> Basically, this boils down to
> 1. clone latest openjdk (or openjdk/mobile)
> 2. clone latest openjfx
> 3. apply a small patch to the openjdk repository (so that it can deal with
> --with-openjfx-modules)
> 4. run the gradle tasks to generate shaderclasses (to be removed)
> 5. configure and make the openjdk image.
>
> We do have GhA scripts that can do the build on-demand, and they can be
> modified to create daily/weekly/... builds. We do not recommend to use
> these scripts for production. At least with Gluon, we do builds from a
> Jenkins system where we have full control over the environment. This allows
> us to use e.g. an ubuntu 24.04 system and deliver binaries that are working
> on ubuntu 20.04, for example.
> The value of the Github Actions, imho, is to easily detect an issue with
> new code in either of the repositories.
>
> An important thing is that this is using the very latest openjdk and
> openjfx code. As I said before: it is not hard to create builds of OpenJFX
> using the OpenJDK for a very specific version, using (very specific)
> patches. The hard thing is to do this without requiring a huge maintenance
> effort.
>
> There are many todo's left, including:
> * make it work on windows, ios and android
> * include media and webkit
> * generate shaders using the OpenJDK code-generate approach
>
> This is an open effort, so everyone is welcome to contribute. But also, if
> others want to use a different approach, I'm all fine with that.
>
> - Johan
>
> Q: Why is this in a repository that is part of the openjdk-mobile
> initiative?
> A: JavaFX is an optional, but crucial part when running Java applications
> on mobile. Since on mobile, it is even more critical to use the correct
> compilers/tools/settings/flags than it is on desktop, it is really
> beneficial to use a single build system for all components that have native
> code. Hence, while building OpenJFX using the OpenJDK build system is very
> useful for desktop platforms, it is almost a requirement when building for
> mobile platforms.
> Note that currently, we only have scripts to build OpenJFX on OpenJDK for
> linux and mac (hence not yet for mobile).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250927/5b612938/attachment.htm>

From arapte at openjdk.org  Sat Sep 27 11:38:34 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sat, 27 Sep 2025 11:38:34 GMT
Subject: Integrated: 8368631: Avoid updating disposed MTLTexture
In-Reply-To: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
References: <H5pe7x9kHyQUfI0b_sL4feB7GVaqAmbHN1BLhEhEy4Y=.565ca487-985c-4997-b273-714d568548c6@github.com>
Message-ID: <vgwEHX3BI7dyAPvI4iqcaEGFlB9NldbA_PR28B1RGr0=.e5aae3b9-b94b-4b99-8496-f655c745050c@github.com>

On Thu, 25 Sep 2025 12:31:01 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: 
> Calling MTLTexture.update() method on a disposed MTLTexture object would cause a crash.
> The root cause of this behavior is [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629).
> 
> Fix:
> Avoid MTLTexture.update() if texture is disposed.
> The crash should be fixed now and the root cause will be followed up using [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629)

This pull request has now been integrated.

Changeset: c480b462
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c480b4622e7a1dc4e1987649eedf972103380b61
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8368631: Avoid updating disposed MTLTexture

Reviewed-by: kcr, aghaisas

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

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

From tsayao at openjdk.org  Sat Sep 27 12:24:55 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 27 Sep 2025 12:24:55 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v65]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <MU1Ij7EAdxWlNBu4Wq2e_6kp4ybG2fSyrbIT0UYRZis=.db1387c5-3978-44b3-823b-2f490206753b@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/6feb43fd..39fb876a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=64
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=63-64

  Stats: 24 lines in 1 file changed: 0 ins; 24 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 Sep 27 12:24:56 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 27 Sep 2025 12:24:56 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v64]
In-Reply-To: <9N7xYPwBzeDve-zx83yeDFRe-wvkCL390bHru14Lvws=.7b4fe6ad-d654-4b3c-959e-b0761d116a4f@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <ijdeuqk_EkUBzQy7nLHb3eCJjCL44qNyykOryPcikbw=.564d05a6-326b-4592-91b5-2d439ca55166@github.com>
 <9N7xYPwBzeDve-zx83yeDFRe-wvkCL390bHru14Lvws=.7b4fe6ad-d654-4b3c-959e-b0761d116a4f@github.com>
Message-ID: <D9xA_v1AGMopEZuGP0keDhxSbR4mK7wcDn9JV8mXZYQ=.5bf7fc3c-da83-4274-b223-f3655e274b70@github.com>

On Tue, 23 Sep 2025 12:21:41 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "8367898: Skip StageFocusTest on Linux"
>>   
>>   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
>
> tests/manual/stage/TestStage.java line 25:
> 
>> 23:  * questions.
>> 24:  */
>> 25: /*
> 
> This file ended up with two same copyright headers, I think we can only keep one :)

Fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2384115104

From tsayao at openjdk.org  Sat Sep 27 12:31:19 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 27 Sep 2025 12:31:19 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v66]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <5z8hC81nG6p8xKCNZXpqeGgmVG2A5yTnI7wOpv0pyNk=.5542f714-d4f3-476a-8608-0011611c799c@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.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao 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 8354943
 - Fix copyright header
 - Revert "8367898: Skip StageFocusTest on Linux"
   
   This reverts commit c95cdcdc9cd8b3070e8076ea91234772d6a21331.
 - Merge branch 'master' into 8354943
 - Remove unused imports
 - - Fix StageOwnershipTest label + minor adjustments
 - Merge branch 'master' into 8354943
 - Merge branch 'master' into 8354943
 - - Fix scene resize when window is unresizable
 - - Fix "Incomplete attachment. (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)(FBO - 820)" when changing view
 - ... and 70 more: https://git.openjdk.org/jfx/compare/c480b462...eb613f8a

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=65
  Stats: 4117 lines in 28 files changed: 2712 ins; 776 del; 629 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 kevin.rushforth at oracle.com  Sat Sep 27 21:59:10 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 27 Sep 2025 14:59:10 -0700
Subject: Building OpenJFX using the OpenJDK build system
In-Reply-To: <CAKjRUT5qFxLbORSUR+zEr93-9HciGfCy=sk8qOpAUdiBdpmVMQ@mail.gmail.com>
References: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>
 <CAKjRUT5qFxLbORSUR+zEr93-9HciGfCy=sk8qOpAUdiBdpmVMQ@mail.gmail.com>
Message-ID: <6d6fd60f-870d-46e8-980a-0affa6555f84@oracle.com>

This looks like quite an interesting project.

> We are back to the great OpenJDK / JFX all-in-one package as it was 
> the case in jdk8 to 10 !

This is largely independent of whether or not to include JavaFX modules 
directly in the JDK if it is to be adopted, although it could make it 
easier to do so. If this is to eventually replace the current gradle 
build system for desktop platforms, a requirement will be to produce 
exactly the same set of build artifacts as gradle does today. By default 
that means producing a set of JMODs, an SDK, and jars suitable for 
publishing to Maven central.

Optionally, it could support linking those modules into the JDK. I note 
that is already possible using jlink on the JMODs produce above, but it 
could be more convenient to have support for direct integration.

Eventually, I might envision an effort that is independent of mobile, 
perhaps using a branch in the jdk-sandbox and jfx-sandbox for 
development. That would make it easy to ensure that the versions of JDK 
and JavaFX sources were compatible and allow experimenting with the 
boundary between what changes should go in the JDK (ideally nothing with 
direct knowledge of JavaFX) and what changes should go into JavaFX.

-- Kevin


On 9/27/2025 3:29 AM, Laurent Bourg?s wrote:
> Hi johan,
>
> We are back to the great OpenJDK / JFX all-in-one package as it was 
> the case in jdk8 to 10 !
>
> I love it,
> Let's go forward now!
>
> Cheers,
> Laurent
>
>
> Le sam. 27 sept. 2025, 11:56, Johan Vos <johan.vos at gluonhq.com> a ?crit?:
>
>     Hi,
>
>     As part of my efforts to build OpenJFX using the OpenJDK build
>     system, I created a script that exactly does this. The script is
>     used in the Github Action in the repository
>     https://github.com/openjdk-mobile/openjfx-build . For questions
>     about why this is done in the openjdk-mobile organisation on
>     github, see below.
>
>     The steps that are executed in the GhA are described in the
>     README.md at https://github.com/openjdk-mobile/openjfx-build .
>     Basically, this boils down to
>     1. clone latest openjdk (or openjdk/mobile)
>     2. clone latest openjfx
>     3. apply a small patch to the openjdk repository (so that it can
>     deal with --with-openjfx-modules)
>     4. run the gradle tasks to generate shaderclasses (to be removed)
>     5. configure and make the openjdk image.
>
>     We do have GhA?scripts?that can do the?build on-demand,?and they
>     can be modified to create daily/weekly/... builds. We do not
>     recommend to use these scripts for production. At least with
>     Gluon, we do builds from a Jenkins system where we have full
>     control over the environment. This allows us to use e.g. an ubuntu
>     24.04 system and deliver binaries that are working on ubuntu
>     20.04, for example.
>     The value of the Github Actions, imho, is to easily detect an
>     issue with new code in either of the repositories.
>
>     An important thing is that this is using the very latest openjdk
>     and openjfx code. As I said before: it is not hard to create
>     builds of OpenJFX using the OpenJDK for a very specific version,
>     using (very specific) patches. The hard thing is to do this
>     without requiring a huge maintenance effort.
>
>     There are many todo's left, including:
>     * make it work on windows, ios and android
>     * include media and webkit
>     * generate shaders using the OpenJDK code-generate approach
>
>     This is an open effort, so everyone is welcome to contribute. But
>     also, if others want to use a different approach, I'm all fine
>     with that.
>
>     - Johan
>
>     Q: Why is this in a repository that is part of the openjdk-mobile
>     initiative?
>     A: JavaFX is an optional, but crucial part when running Java
>     applications on mobile. Since on mobile, it is even?more critical
>     to use the correct compilers/tools/settings/flags than it is on
>     desktop, it is really beneficial to use a single build system for
>     all components that have native code. Hence, while building
>     OpenJFX using the OpenJDK build system is very useful for desktop
>     platforms, it is almost a requirement when building for mobile
>     platforms.
>     Note that currently, we only have scripts to build OpenJFX on
>     OpenJDK for linux and mac (hence not yet for mobile).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250927/6f089c4f/attachment-0001.htm>

From johan.vos at gluonhq.com  Sun Sep 28 13:52:22 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 28 Sep 2025 15:52:22 +0200
Subject: Building OpenJFX using the OpenJDK build system
In-Reply-To: <6d6fd60f-870d-46e8-980a-0affa6555f84@oracle.com>
References: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>
 <CAKjRUT5qFxLbORSUR+zEr93-9HciGfCy=sk8qOpAUdiBdpmVMQ@mail.gmail.com>
 <6d6fd60f-870d-46e8-980a-0affa6555f84@oracle.com>
Message-ID: <CABxFH2FaLh32UT9iSE4wmwHtYfgMT-19yk5WN3HmrRxuF+vTyQ@mail.gmail.com>

On Sat, Sep 27, 2025 at 11:59?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> This looks like quite an interesting project.
>
> We are back to the great OpenJDK / JFX all-in-one package as it was the
> case in jdk8 to 10 !
>
>
> This is largely independent of whether or not to include JavaFX modules
> directly in the JDK if it is to be adopted, although it could make it
> easier to do so. If this is to eventually replace the current gradle build
> system for desktop platforms, a requirement will be to produce exactly the
> same set of build artifacts as gradle does today. By default that means
> producing a set of JMODs, an SDK, and jars suitable for publishing to Maven
> central.
>

I agree, those artifacts need to be produced and they have to be similar to
what we currently have with the gradle-based builds.


> Optionally, it could support linking those modules into the JDK. I note
> that is already possible using jlink on the JMODs produce above, but it
> could be more convenient to have support for direct integration.
>

I think the difference between this project and what is currently possible
using jlink is more than just convenience.
When using jlink to create a JRE, there is no guarantee that the modules
are built in a consistent approach. Hence, it is possible to have the core
modules built against glibc 2.39 and the javafx modules built against glibc
2.35.
When building everything from the same build tools, we ensure that the
native libraries are very consistent with each other. It also makes
maintenance of OpenJFX easier, as we regularly update the minimum
requirements of some dependencies because they are updated in OpenJDK.

The additional jlink step that is currently needed if one wants to
distribute a JRE with JavaFX requires "unpacking" 2 projects, mixing some
artifacts, and repackaging it. While the tools do this is are really great,
it is still more plumbing work than the case where the `make images` is
used when compiling the JDK and where the JavaFX modules are immediately
part of the image.

Eventually, I might envision an effort that is independent of mobile,
> perhaps using a branch in the jdk-sandbox and jfx-sandbox for development.
> That would make it easy to ensure that the versions of JDK and JavaFX
> sources were compatible and allow experimenting with the boundary between
> what changes should go in the JDK (ideally nothing with direct knowledge of
> JavaFX) and what changes should go into JavaFX.
>

Absolutely, that would be a great experiment. And I agree the required
effort for the OpenJDK build procedures should ideally be zero.


>
> -- Kevin
>
>
> On 9/27/2025 3:29 AM, Laurent Bourg?s wrote:
>
> Hi johan,
>
> We are back to the great OpenJDK / JFX all-in-one package as it was the
> case in jdk8 to 10 !
>
> I love it,
> Let's go forward now!
>
> Cheers,
> Laurent
>
>
> Le sam. 27 sept. 2025, 11:56, Johan Vos <johan.vos at gluonhq.com> a ?crit :
>
>> Hi,
>>
>> As part of my efforts to build OpenJFX using the OpenJDK build system, I
>> created a script that exactly does this. The script is used in the Github
>> Action in the repository https://github.com/openjdk-mobile/openjfx-build
>> . For questions about why this is done in the openjdk-mobile organisation
>> on github, see below.
>>
>> The steps that are executed in the GhA are described in the README.md at
>> https://github.com/openjdk-mobile/openjfx-build .
>> Basically, this boils down to
>> 1. clone latest openjdk (or openjdk/mobile)
>> 2. clone latest openjfx
>> 3. apply a small patch to the openjdk repository (so that it can deal
>> with --with-openjfx-modules)
>> 4. run the gradle tasks to generate shaderclasses (to be removed)
>> 5. configure and make the openjdk image.
>>
>> We do have GhA scripts that can do the build on-demand, and they can be
>> modified to create daily/weekly/... builds. We do not recommend to use
>> these scripts for production. At least with Gluon, we do builds from a
>> Jenkins system where we have full control over the environment. This allows
>> us to use e.g. an ubuntu 24.04 system and deliver binaries that are working
>> on ubuntu 20.04, for example.
>> The value of the Github Actions, imho, is to easily detect an issue with
>> new code in either of the repositories.
>>
>> An important thing is that this is using the very latest openjdk and
>> openjfx code. As I said before: it is not hard to create builds of OpenJFX
>> using the OpenJDK for a very specific version, using (very specific)
>> patches. The hard thing is to do this without requiring a huge maintenance
>> effort.
>>
>> There are many todo's left, including:
>> * make it work on windows, ios and android
>> * include media and webkit
>> * generate shaders using the OpenJDK code-generate approach
>>
>> This is an open effort, so everyone is welcome to contribute. But also,
>> if others want to use a different approach, I'm all fine with that.
>>
>> - Johan
>>
>> Q: Why is this in a repository that is part of the openjdk-mobile
>> initiative?
>> A: JavaFX is an optional, but crucial part when running Java applications
>> on mobile. Since on mobile, it is even more critical to use the correct
>> compilers/tools/settings/flags than it is on desktop, it is really
>> beneficial to use a single build system for all components that have native
>> code. Hence, while building OpenJFX using the OpenJDK build system is very
>> useful for desktop platforms, it is almost a requirement when building for
>> mobile platforms.
>> Note that currently, we only have scripts to build OpenJFX on OpenJDK for
>> linux and mac (hence not yet for mobile).
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250928/875b5c2f/attachment.htm>

From tsayao at openjdk.org  Sun Sep 28 14:05:30 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 14:05:30 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
Message-ID: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>

The bug report is on Linux Mint which does not use ibus (the gnome default).

With this change, it continues to work on ibus, but also works works without it (on mint).

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

Commit messages:
 - 8367045
 - 8367045
 - 8367045
 - 8367045
 - 8367045
 - 8367045
 - 8367045
 - 8367045
 - IME

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

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

From tsayao at openjdk.org  Sun Sep 28 14:26:11 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 14:26:11 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v2]
In-Reply-To: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
Message-ID: <ARmuNvZY1pkFrhm88c3LB1usAn957ixPWUY7uSFNPQA=.facf7399-b49d-4077-a1bc-e3aa3a76a0db@github.com>

> The bug report is on Linux Mint which does not use ibus (the gnome default).
> 
> With this change, it continues to work on ibus, but also works works without it (on mint).

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  revert Unecessary changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1922/files
  - new: https://git.openjdk.org/jfx/pull/1922/files/33c284cc..d72196c4

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

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

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

From tsayao at openjdk.org  Sun Sep 28 15:16:14 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 15:16:14 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v3]
In-Reply-To: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
Message-ID: <O4RJHz5NFnf__VUERfy3ajpdJfyK09uNl2YeR6lQkNk=.180801c1-d87a-4942-8f00-05df39ec0a8f@github.com>

> The bug report is on Linux Mint which does not use ibus (the gnome default).
> 
> With this change, it continues to work on ibus, but also works works without it (on mint).
> 
> Tested with fcitx too.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  setting IBUS_ENABLE_SYNC_MODE seems to be not required with the other changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1922/files
  - new: https://git.openjdk.org/jfx/pull/1922/files/d72196c4..15935c15

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

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

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

From tsayao at openjdk.org  Sun Sep 28 15:34:09 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 15:34:09 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v4]
In-Reply-To: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
Message-ID: <LTD39zmBiEA3rij9daYC8ti_ikd_0E6y-KwAm94uAyA=.8ee949ca-0561-472d-b93b-6016c7c21f6f@github.com>

> The bug report is on Linux Mint which does not use ibus (the gnome default).
> 
> With this change, it continues to work on ibus, but also works works without it (on mint).
> 
> Tested with fcitx too.

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Remove send_keypress
 - Remove send_keypress

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1922/files
  - new: https://git.openjdk.org/jfx/pull/1922/files/15935c15..9e4157df

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

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

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

From tsayao at openjdk.org  Sun Sep 28 15:34:11 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 15:34:11 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v3]
In-Reply-To: <O4RJHz5NFnf__VUERfy3ajpdJfyK09uNl2YeR6lQkNk=.180801c1-d87a-4942-8f00-05df39ec0a8f@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <O4RJHz5NFnf__VUERfy3ajpdJfyK09uNl2YeR6lQkNk=.180801c1-d87a-4942-8f00-05df39ec0a8f@github.com>
Message-ID: <o5zTgRSbOJSv_LubYSFRWbN-NQAG6lYQNEY2m5rtd6c=.c6260c57-178b-4b16-96f6-73c4efcc43dd@github.com>

On Sun, 28 Sep 2025 15:16:14 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The bug report is on Linux Mint which does not use ibus (the gnome default).
>> 
>> With this change, it continues to work on ibus, but also works works without it (on mint).
>> 
>> Tested with fcitx too.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setting IBUS_ENABLE_SYNC_MODE seems to be not required with the other changes

I'm not sure why it works now, still needs some investigation.

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3343758843

From tsayao at openjdk.org  Sun Sep 28 20:05:43 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 20:05:43 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v5]
In-Reply-To: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
Message-ID: <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>

> The bug report is on Linux Mint which does not use ibus (the gnome default).
> 
> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
> 
> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
> 
> @Glavo: Can you check if Chinese input is still correct?
> @andzsinszan: Can you check for Japanese?

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Restore IBUS_ENABLE_SYNC_MODE
 - Restore IBUS_ENABLE_SYNC_MODE

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1922/files
  - new: https://git.openjdk.org/jfx/pull/1922/files/9e4157df..a9ea6ba7

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

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

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

From mfox at openjdk.org  Sun Sep 28 20:05:44 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sun, 28 Sep 2025 20:05:44 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v4]
In-Reply-To: <LTD39zmBiEA3rij9daYC8ti_ikd_0E6y-KwAm94uAyA=.8ee949ca-0561-472d-b93b-6016c7c21f6f@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <LTD39zmBiEA3rij9daYC8ti_ikd_0E6y-KwAm94uAyA=.8ee949ca-0561-472d-b93b-6016c7c21f6f@github.com>
Message-ID: <gQEXVi7JtAsvVFZoB7AfDGFpqmLpbzmyujoStw4mF34=.adf0d13a-7875-4c87-b4a8-44ae2e3dd2f1@github.com>

On Sun, 28 Sep 2025 15:34:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The bug report is on Linux Mint which does not use ibus (the gnome default).
>> 
>> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
>> 
>> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
>> 
>> @Glavo: Can you check if Chinese input is still correct?
>> @andzsinszan: Can you check for Japanese?
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove send_keypress
>  - Remove send_keypress

With this PR all text input is delivered as committed text in an InputMethodEvent. JavaFX never receives  a KEY_TYPED KeyEvent. This simplifies things but will cause all manner of follow-on problems. We need a better solution.

I cannot easily run Linux Mint since it doesn't provide an ARM version. This bug does not reproduce for me in a stock Ubuntu 24.04.3 environment which defaults to IBus. Does Linux Mint default to a different input method framework such as fcitx?

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3344206998

From tsayao at openjdk.org  Sun Sep 28 21:07:27 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 21:07:27 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v4]
In-Reply-To: <gQEXVi7JtAsvVFZoB7AfDGFpqmLpbzmyujoStw4mF34=.adf0d13a-7875-4c87-b4a8-44ae2e3dd2f1@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <LTD39zmBiEA3rij9daYC8ti_ikd_0E6y-KwAm94uAyA=.8ee949ca-0561-472d-b93b-6016c7c21f6f@github.com>
 <gQEXVi7JtAsvVFZoB7AfDGFpqmLpbzmyujoStw4mF34=.adf0d13a-7875-4c87-b4a8-44ae2e3dd2f1@github.com>
Message-ID: <mTme17DDyvF9QNQ77G6uCfEaeeX2019lDsE4wFHbOdA=.ea61c323-bd80-4aef-80fe-ab1042059480@github.com>

On Sun, 28 Sep 2025 20:02:57 GMT, Martin Fox <mfox at openjdk.org> wrote:

> With this PR all text input is delivered as committed text in an InputMethodEvent. JavaFX never receives a KEY_TYPED KeyEvent. This simplifies things but will cause all manner of follow-on problems. We need a better solution.
> 
> I cannot easily run Linux Mint since it doesn't provide an ARM version. This bug does not reproduce for me in a stock Ubuntu 24.04.3 environment which defaults to IBus. Does Linux Mint default to a different input method framework such as fcitx?

Thanks for refreshing my memory - I had a feeling that I was missing something.

The equivalent on Ubuntu would be to launch `im-config`, select `xim` and restart the session with Xorg.

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3344254143

From tsayao at openjdk.org  Sun Sep 28 21:32:27 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Sep 2025 21:32:27 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v5]
In-Reply-To: <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
Message-ID: <8EhMwZK3S--Z0H0EKQ44BjJFpnbkvDo8Wuc9nZigLt4=.e9a993ad-2e6e-4b60-9620-7d20bb13fde6@github.com>

On Sun, 28 Sep 2025 20:05:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The bug report is on Linux Mint which does not use ibus (the gnome default).
>> 
>> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
>> 
>> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
>> 
>> @Glavo: Can you check if Chinese input is still correct?
>> @andzsinszan: Can you check for Japanese?
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore IBUS_ENABLE_SYNC_MODE
>  - Restore IBUS_ENABLE_SYNC_MODE

Typed e followed by ' on a Brazilian Portuguese keyboard to output ? and then typed "ni hao"  with Chinese Pinyin.

master branch:
<img width="668" height="706" alt="image" src="https://github.com/user-attachments/assets/90c57d9d-c569-4029-a8c7-27caf4a4cb1d" />

with this PR:
<img width="668" height="706" alt="image" src="https://github.com/user-attachments/assets/7163dad0-11e2-4b8e-aaf8-ead5b3430ea0" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3344277504

From kevin.rushforth at oracle.com  Mon Sep 29 12:02:22 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Sep 2025 05:02:22 -0700
Subject: [External] : Re: Building OpenJFX using the OpenJDK build system
In-Reply-To: <CABxFH2FaLh32UT9iSE4wmwHtYfgMT-19yk5WN3HmrRxuF+vTyQ@mail.gmail.com>
References: <CABxFH2HuQqim6jzQZB1uE-R+juHuaua0nMZendCJ5k4r=7Xfvw@mail.gmail.com>
 <CAKjRUT5qFxLbORSUR+zEr93-9HciGfCy=sk8qOpAUdiBdpmVMQ@mail.gmail.com>
 <6d6fd60f-870d-46e8-980a-0affa6555f84@oracle.com>
 <CABxFH2FaLh32UT9iSE4wmwHtYfgMT-19yk5WN3HmrRxuF+vTyQ@mail.gmail.com>
Message-ID: <ed733311-8a1b-4b82-9ce8-b6fba0f639aa@oracle.com>



On 9/28/2025 6:52 AM, Johan Vos wrote:
>
>
> On Sat, Sep 27, 2025 at 11:59?PM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
> ...
>
>     Optionally, it could support linking those modules into the JDK. I
>     note that is already possible using jlink on the JMODs produce
>     above, but it could be more convenient to have support for direct
>     integration.
>
>
> I think the difference between this project and what is currently 
> possible using jlink is more than just convenience.
> When using jlink to create a JRE, there is no guarantee that the 
> modules are built in a consistent approach. Hence, it is possible to 
> have the core modules built against glibc 2.39 and the javafx modules 
> built against glibc 2.35.
> When building everything from the same build tools, we ensure that the 
> native libraries are very consistent with each other. It also makes 
> maintenance of OpenJFX easier, as we regularly update the minimum 
> requirements of some dependencies because they are updated in OpenJDK.

What I meant is that you could use this project to separately build the 
JDK and then JavaFX JMODs using the exact same toolchains and then use 
jlink to create a JDK with JavaFX modules. In that way, you would ensure 
consistency in building the native libs. However, as you point out below...

> The additional jlink step that is currently needed if one wants to 
> distribute a JRE with JavaFX requires "unpacking" 2 projects, mixing 
> some artifacts, and repackaging it. While the tools do this is are 
> really great, it is still more plumbing work than the case where the 
> `make images` is used when compiling the JDK and where the JavaFX 
> modules are immediately part of the image.

Yes, this is definitely easier and seems well worth supporting as a 
better way to build a JDK that includes JavaFX modules. And in addition 
to the repackaging, it would need to be signed (and on macOS notarized) 
again.

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

From kcr at openjdk.org  Mon Sep 29 13:41:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 29 Sep 2025 13:41:36 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
References: <ODRwWkDQrzYTw2soE3aqvlG9Hus4HrWZTLlm8nj0Pmk=.3b95fc44-0f3f-466e-b76d-2e572be02ca2@github.com>
 <eWiW0IUgVCQ2xxuuUku1xPjID2GfxuQb5kK9-qGYP2Y=.07f621c8-1947-4fd5-828e-dc2c214bcfe9@github.com>
Message-ID: <cvDnVSscUklrlt6KMou1wfLlqsTtaNcSQoZwAgg6zIk=.6e9f79e3-918d-4168-9cf9-c479778850b7@github.com>

On Mon, 22 Sep 2025 23:52:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Given a media query with more than one rule:
>> 
>> 
>> @media (prefers-color-scheme: dark) {
>>     .foo1 {
>>         -fx-background-color: black;
>>     }
>>     .foo2 {
>>         -fx-background-color: white;
>>     }
>> }
>> 
>> 
>> The following CSS parser error is encountered: `Expected RBRACE`
>> 
>> The reason for this bug is that the CSS parser mistakenly expects that after the first rule was parsed, the media query should be terminated with a closing curly brace. This is obviously incorrect, the fix is relatively simple.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   emit error when closing curly brace is missing

@arapte Can you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1915#issuecomment-3347017609

From zelmidaoui at openjdk.org  Mon Sep 29 17:16:50 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 29 Sep 2025 17:16:50 GMT
Subject: RFR: 8368511: Incorrect "Group" name after click on link in JavaFX CSS
 Reference Guide
Message-ID: <Plcub1ceANKEdo2imnxpH-Do4PLUdfaSJDlFpZvaL8Y=.db316e24-9385-499b-af44-eb8a81663f0a@github.com>

Changed `Group` name to `PopupWindow` in `cssref.html`

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

Commit messages:
 - Fix incorrect "Group" heading to "PopupWindow" in cssref.html

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

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

From kevin.rushforth at oracle.com  Mon Sep 29 19:29:39 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Sep 2025 12:29:39 -0700
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
Message-ID: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>

I hereby nominate Ziad El Midaoui [1] to OpenJFX Committer.

Ziad is a member of the JavaFX team at Oracle who has contributed 12 
commits [2] to OpenJFX.

Votes are due by October 13, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project 
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#zelmidaoui

[2] 
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Ziad+El+Midaoui%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer


From kevin.rushforth at oracle.com  Mon Sep 29 19:30:27 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Sep 2025 12:30:27 -0700
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
In-Reply-To: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
References: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
Message-ID: <d25a59da-cc98-46b3-9c04-56931782ea61@oracle.com>

Vote: YES

-- Kevin

On 9/29/2025 12:29 PM, Kevin Rushforth wrote:
> I hereby nominate Ziad El Midaoui [1] to OpenJFX Committer.
>
> Ziad is a member of the JavaFX team at Oracle who has contributed 12 
> commits [2] to OpenJFX.
>
> Votes are due by October 13, 2025 at 20:00 UTC.
>
> Only current OpenJFX Committers [3] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [4]. Nomination to a 
> project Committer is described in [5].
>
> Thanks.
>
> -- Kevin
>
>
> [1] https://openjdk.org/census#zelmidaoui
>
> [2] 
> https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Ziad+El+Midaoui%22&type=commits
>
> [3] https://openjdk.org/census#openjfx
>
> [4] https://openjdk.org/bylaws#lazy-consensus
>
> [5] https://openjdk.org/projects#project-committer
>


From andy.goryachev at oracle.com  Mon Sep 29 19:31:13 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 29 Sep 2025 19:31:13 +0000
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
In-Reply-To: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
References: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
Message-ID: <DS0PR10MB727198766D1073E0D25CF49FE51BA@DS0PR10MB7271.namprd10.prod.outlook.com>

Vote: YES

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Monday, September 29, 2025 at 12:29
To: openjfx-dev <openjfx-dev at openjdk.org>, Ziad El Midaoui <ziad.el.midaoui at oracle.com>
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui

I hereby nominate Ziad El Midaoui [1] to OpenJFX Committer.

Ziad is a member of the JavaFX team at Oracle who has contributed 12
commits [2] to OpenJFX.

Votes are due by October 13, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#zelmidaoui

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Ziad+El+Midaoui%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer

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

From philip.race at oracle.com  Mon Sep 29 20:01:38 2025
From: philip.race at oracle.com (Phil Race)
Date: Mon, 29 Sep 2025 13:01:38 -0700
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
In-Reply-To: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
References: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
Message-ID: <56f1708e-b652-4d2b-ba3e-4ef27629c7b0@oracle.com>

Vote: yes

-phil.


From mfox at openjdk.org  Mon Sep 29 20:09:02 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 29 Sep 2025 20:09:02 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v5]
In-Reply-To: <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
Message-ID: <Z9DTy6mfEaov7f5U07SUfLbiNfri2l3XCPBHFoTr2i4=.8fae6e5a-afde-4c0a-8cf4-40d12d2b58b9@github.com>

On Sun, 28 Sep 2025 20:05:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The bug report is on Linux Mint which does not use ibus (the gnome default).
>> 
>> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
>> 
>> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
>> 
>> @Glavo: Can you check if Chinese input is still correct?
>> @andzsinszan: Can you check for Japanese?
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore IBUS_ENABLE_SYNC_MODE
>  - Restore IBUS_ENABLE_SYNC_MODE

I've updated the original bug report with more details. I'll submit a PR, the solution is similar to work I did on the Mac side.

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3348859055

From kcr at openjdk.org  Mon Sep 29 21:53:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 29 Sep 2025 21:53:14 GMT
Subject: RFR: 8368021: Window buttons of extended RTL stage are on the
 wrong side
In-Reply-To: <FgoP-JrLHGHWC-uEjOdd0awhb4KllXmjiIodPDA8SIk=.505371ab-f871-419c-a3a6-27dad64a44a1@github.com>
References: <FgoP-JrLHGHWC-uEjOdd0awhb4KllXmjiIodPDA8SIk=.505371ab-f871-419c-a3a6-27dad64a44a1@github.com>
Message-ID: <GBbuXoCaUIdf8kblv3UMczHNakDLVkHScm2Lh9AWwDE=.ae3f180b-cbb1-4846-a2a1-f398ed2cb751@github.com>

On Sat, 27 Sep 2025 04:56:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When an extended stage is shown with RTL orientation (either using a RTL window + `Scene.nodeOrientation == INHERIT`, or using a LTR window and `Scene.nodeOrientation == RIGHT_TO_LEFT`), the default window buttons are placed on the wrong side of the window. This bug only manifests on Windows and Linux, both of which use `HeaderButtonOverlay` to render the default window buttons.
> 
> `HeaderButtonOverlay` is not a part of the scene graph, it is shown on top of the scene graph as an overlay (like the warning overlay that appears when entering full-screen mode). For [CSS-related reasons](https://github.com/openjdk/jfx/pull/1605#issuecomment-2967977276), the parent of an overlay is the scene root (but the scene root doesn't know that). This implementation detail can mess up the calculation of orientation flags and mirroring transforms in `Node`, as depending on the `NodeOrientation` of the root node, the code may mistakenly mirror (or not mirror) the orientation.
> 
> The solution I've come up with is as follows: the overlay node is marked with the `Node.INHERIT_ORIENTATION_FROM_SCENE` flag, which causes it to resolve its effective orientation against the scene only, and never against the root node. With this change, the effective orientation and mirroring transforms are computed correctly.
> 
> The easiest way to test this fix is with Monkey Tester -> Tools -> Stage Tester.

This looks like a reasonable fix to me.

Reviewers: @andy-goryachev-oracle @Ziad-Mid

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

PR Comment: https://git.openjdk.org/jfx/pull/1921#issuecomment-3349175968

From angorya at openjdk.org  Mon Sep 29 22:53:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 29 Sep 2025 22:53:58 GMT
Subject: RFR: 8368511: Incorrect "Group" name after click on link in JavaFX
 CSS Reference Guide
In-Reply-To: <Plcub1ceANKEdo2imnxpH-Do4PLUdfaSJDlFpZvaL8Y=.db316e24-9385-499b-af44-eb8a81663f0a@github.com>
References: <Plcub1ceANKEdo2imnxpH-Do4PLUdfaSJDlFpZvaL8Y=.db316e24-9385-499b-af44-eb8a81663f0a@github.com>
Message-ID: <B0wKyc10ABn-5BqQPWKlBuDIWmTc_ULsLAEgZSMVEfA=.ce160e47-929a-4d84-80d8-10f7ed8c7cac@github.com>

On Mon, 29 Sep 2025 13:50:19 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Changed `Group` name to `PopupWindow` in `cssref.html`

took 8 years for this issue to be discovered...

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1923#pullrequestreview-3282056606

From lukasz.kostyra at oracle.com  Tue Sep 30 06:08:12 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Tue, 30 Sep 2025 06:08:12 +0000
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
In-Reply-To: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
References: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
Message-ID: <DM3PPF3367D7B9B53EF014C35F9305296D3FE1AA@DM3PPF3367D7B9B.namprd10.prod.outlook.com>

Vote: YES

-Lukasz

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Monday, 29 September 2025 at 21:29
To: openjfx-dev <openjfx-dev at openjdk.org>, Ziad El Midaoui <ziad.el.midaoui at oracle.com>
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui

I hereby nominate Ziad El Midaoui [1] to OpenJFX Committer.

Ziad is a member of the JavaFX team at Oracle who has contributed 12
commits [2] to OpenJFX.

Votes are due by October 13, 2025 at 20:00 UTC.

Only current OpenJFX Committers [3] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4]. Nomination to a project
Committer is described in [5].

Thanks.

-- Kevin


[1] https://openjdk.org/census#zelmidaoui

[2]
https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Ziad+El+Midaoui%22&type=commits

[3] https://openjdk.org/census#openjfx

[4] https://openjdk.org/bylaws#lazy-consensus

[5] https://openjdk.org/projects#project-committer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250930/e4c69797/attachment.htm>

From duke at openjdk.org  Tue Sep 30 08:41:50 2025
From: duke at openjdk.org (duke)
Date: Tue, 30 Sep 2025 08:41:50 GMT
Subject: Withdrawn: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <2a9F5SyS6zCoimwbfnLtl5StoMD4xjfjbJyRyY1c-jw=.7cda60d1-515c-40c0-a8f1-4a54f2e93375@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

This pull request has been closed without being integrated.

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

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

From mhanl at openjdk.org  Tue Sep 30 09:01:50 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 30 Sep 2025 09:01:50 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
Message-ID: <OkVpiWSVGKlwkEkAFnMnQ3atNvm84hq2qFaHeaZV8LI=.110d8361-8ff7-4d90-814c-e01759b0bb97@github.com>

On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
> 
> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
> 
> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
> 
> The contract of `refresh()` is also a big vague, stating:
> 
> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
> necessary to populate the visual bounds of the control.
> In other words, this forces the XXX to update what it is showing to the user. 
> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
> 
> 
> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).

Will do the CSR + try to benchmark when I have more time!

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3350795470

From john at status6.com  Tue Sep 30 16:04:02 2025
From: john at status6.com (John Neffenger)
Date: Tue, 30 Sep 2025 09:04:02 -0700
Subject: CFV: New OpenJFX Committer: Ziad El Midaoui
In-Reply-To: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
References: <6865ec91-4775-47be-bc04-9bb45f65a3c0@oracle.com>
Message-ID: <926833f6-8c3d-461c-b432-7eb5bcfa157c@status6.com>

Vote: YES

John

On 9/29/25 12:29 PM, Kevin Rushforth wrote:
> I hereby nominate Ziad El Midaoui [1] to OpenJFX Committer.
> 
> [1] https://openjdk.org/census#zelmidaoui


From kcr at openjdk.org  Tue Sep 30 16:54:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Sep 2025 16:54:12 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
Message-ID: <Fvrv558yAwMZOe8j-H_DLjeH_wFBO3kwpzAaI3_SxB0=.60c08888-ee9c-485a-bc17-70bce1c35a0d@github.com>

On Sat, 23 Aug 2025 14:26:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Support background loading of raw input streams
>> 
>> - Fixed generics (mix up of two ImageLoader types)
>> - Removed unused code for handling headers, methods, request parameters
>> - Use `long` for progress as streams may exceed 2 GB
>> - Improved documentation of Image regarding background loading
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify documentation with regards to stream closing

The new API and code changes look good with one comment on the docs. In a few places you say "the image loading is performed immediately and is completed _after_ this constructor returns". The word "after" is misleading in that it could imply some sort of async behavior. I recommend changing it to "when", which you already use in other places.

I left one other minor formatting issue that I happened to spot.

I think that this is ready for the CSR once you change "after" to "when" in the various places.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 829:

> 827:             String protocol = u.getProtocol();
> 828: 
> 829:             if(protocol.equals("http") || protocol.equals("https")) {

Minor: add a space after `if`.

modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 625:

> 623:      * <p>
> 624:      * The image loading is performed immediately and is completed after this
> 625:      * constructor returns.

I think it would it be clearer to say that it is completed "when" this constructor returns, as you do in a couple other places. As it is "after ... returns" could mislead someone into thinking that the operation might not be complete upon return.

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

PR Review: https://git.openjdk.org/jfx/pull/1875#pullrequestreview-3285769936
PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2392152597
PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2392164552

From angorya at openjdk.org  Tue Sep 30 16:54:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Sep 2025 16:54:12 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <UeWFhxeqt7Nbzf065P84fJrxtKNycmDVwTfEJbfPD6Y=.4f258ad6-eb0f-4192-a92c-a4c3818a02ec@github.com>
Message-ID: <sH8f48ocecjz0uj8sTSDAVlfeTWzNbbH6Xu-nsG4zXA=.3eda3f7e-9883-4c89-ad0b-e4982c72d5fe@github.com>

On Sat, 23 Aug 2025 14:26:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Support background loading of raw input streams
>> 
>> - Fixed generics (mix up of two ImageLoader types)
>> - Removed unused code for handling headers, methods, request parameters
>> - Use `long` for progress as streams may exceed 2 GB
>> - Improved documentation of Image regarding background loading
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify documentation with regards to stream closing

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 829:

> 827:             String protocol = u.getProtocol();
> 828: 
> 829:             if(protocol.equals("http") || protocol.equals("https")) {

minor suggestion: `"http".equals()`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2392250091

From kcr at openjdk.org  Tue Sep 30 17:13:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Sep 2025 17:13:29 GMT
Subject: RFR: 8360940: Layout stops updating when using
 Parent#setNeedsLayout(true) due to incorrect state management
In-Reply-To: <qBa3rqWdnxHA7FYaTGqx5OelYTT2bzA53-JMUgmAzFg=.61fa75c5-95bb-42bd-8c1e-ca57c366d319@github.com>
References: <qBa3rqWdnxHA7FYaTGqx5OelYTT2bzA53-JMUgmAzFg=.61fa75c5-95bb-42bd-8c1e-ca57c366d319@github.com>
Message-ID: <5c_d7jFu8us7HD7TwbuCbsg4yGH3w6ONrvS_g6emOfg=.9505ab7e-0b62-4921-a65e-53d6cdf91a8f@github.com>

On Sat, 23 Aug 2025 14:58:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Ensures proper propagation of layout flags when using `forceParentLayout = true`.
> 
> This was the root cause of issue #1874
> 
> ### Note
> 
> Apparently it is still quite easy to mess up the layout flags. Basically, the layout flag tracked by Parent should always either be `CLEAN` for any scene graph branch, or `!CLEAN` + a layout pulse is scheduled on the corresponding `Scene`.
> 
> However, with careful use of the public API `requestLayout` one can get these flags in a bad state still:
> 
> Let's say I have a branch `A (root node under Scene) -> B -> C`, **and** a layout is in progress, **and** we're currently in the `layoutChildren` method of `C`. The flag `performingLayout` will be `true` for all nodes in the branch `A` ->  `B` -> `C`.  The `layout` method will set the layout flag to `CLEAN` as its first action, so when we're at `C::layoutChildren`, all flags have been reset to `CLEAN` already.  See the `Parent::layout` method for how all this works.
> 
> Now, to mess up the flags, all you need to do is call `requestLayout` on `B` or `C` from the `layoutChildren` of `C` (or indirectly by changing something and something is listening to this and schedules a layout on something somewhere in this branch); note that `requestLayout` is not documented to be illegal to call during layout, and some classes in FX will do so (ScrollPaneSkin, NumberAxis, etc..) risking the flags getting in a bad state... -- usually you get away with this, as there are many ways that layout is triggered, and eventually the flags will get overwritten and reset to a consistent state.
> 
> The bad state occurs because this code path is followed (all code from `Parent`):
> 
>     public void requestLayout() {
>         clearSizeCache();
>         markDirtyLayout(false, forceParentLayout);
>     }
>     
> Calls to `markDirtyLayout(false, false)`:
> 
>     private void markDirtyLayout(boolean local, boolean forceParentLayout) {
>         setLayoutFlag(LayoutFlags.NEEDS_LAYOUT);
>         if (local || layoutRoot) {
>             if (sceneRoot) {
>                 Toolkit.getToolkit().requestNextPulse();
>                 if (getSubScene() != null) {
>                     getSubScene().setDirtyLayout(this);
>                 }
>             } else {
>                 markDirtyLayoutBranch();
>             }
>         } else {
>             requestParentLayout(forceParentLayout);
>         }
>     }
>     
> Before going into the `else` (as none of the nodes is a layout root, and `local` was set to `false`) it will do **setLayoutFlag(LayoutFlags.NEEDS_LAYOUT)** ...

The fix looks good. I confirm that the manual test program from the JBS bug fails without the fix and passes with the fix.

Would it be possible to turn it into an automated test?

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

PR Review: https://git.openjdk.org/jfx/pull/1879#pullrequestreview-3285966396

From mfox at openjdk.org  Tue Sep 30 18:25:15 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Sep 2025 18:25:15 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
Message-ID: <JdPzu9ihosDyLCS6tmPSipU66khPqaDLqUFy-HKk7y8=.c661e314-74d8-440d-9247-cc331b1909a2@github.com>

This bug seems to only apply to Linux systems with no input method framework (IMF) configured. If you want to reproduce the original bug on Ubuntu 24.04 you need to go into Settings > System > "Region & Language" > "Manage installed languages" > Language and verify that "Keyboard input method system" is set to "none". If you change this setting you should reboot the system.

Normally at the end of a dead-key sequence the IMF sends us a "commit" with the composed character followed by a "preedit-end" signal. When no IMF is configured these signals arrive in reverse order. This is not the way any IMF works and is confusing the heuristic we use to determine whether to send a KeyEvent or an InputMethodEvent.

To insulate ourselves against this signal ordering issue we add a new flag that ensures that if we're in the preedit window when we start filtering an event we stay there until filtering is done.

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

Commit messages:
 - Ensure pre-edit logic applies regardless of signal order

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

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

From angorya at openjdk.org  Tue Sep 30 18:52:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Sep 2025 18:52:26 GMT
Subject: RFR: 8368021: Window buttons of extended RTL stage are on the
 wrong side
In-Reply-To: <FgoP-JrLHGHWC-uEjOdd0awhb4KllXmjiIodPDA8SIk=.505371ab-f871-419c-a3a6-27dad64a44a1@github.com>
References: <FgoP-JrLHGHWC-uEjOdd0awhb4KllXmjiIodPDA8SIk=.505371ab-f871-419c-a3a6-27dad64a44a1@github.com>
Message-ID: <DvLaZDzy7Jgwj_P_jdvGbllKsJLKLKQg7cI_n5stwIk=.7ce6fa5d-d505-418d-96ff-4f99b66fb3a5@github.com>

On Sat, 27 Sep 2025 04:56:51 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> When an extended stage is shown with RTL orientation (either using a RTL window + `Scene.nodeOrientation == INHERIT`, or using a LTR window and `Scene.nodeOrientation == RIGHT_TO_LEFT`), the default window buttons are placed on the wrong side of the window. This bug only manifests on Windows and Linux, both of which use `HeaderButtonOverlay` to render the default window buttons.
> 
> `HeaderButtonOverlay` is not a part of the scene graph, it is shown on top of the scene graph as an overlay (like the warning overlay that appears when entering full-screen mode). For [CSS-related reasons](https://github.com/openjdk/jfx/pull/1605#issuecomment-2967977276), the parent of an overlay is the scene root (but the scene root doesn't know that). This implementation detail can mess up the calculation of orientation flags and mirroring transforms in `Node`, as depending on the `NodeOrientation` of the root node, the code may mistakenly mirror (or not mirror) the orientation.
> 
> The solution I've come up with is as follows: the overlay node is marked with the `Node.INHERIT_ORIENTATION_FROM_SCENE` flag, which causes it to resolve its effective orientation against the scene only, and never against the root node. With this change, the effective orientation and mirroring transforms are computed correctly.
> 
> The easiest way to test this fix is with Monkey Tester -> Tools -> Stage Tester.

Works as expected on windows 11 (using the monkey tester).
No ill effects on macOS.

One minor suggestion.

Did not test on Linux - @Ziad-Mid could you please test on Linux?
Also, could you test the behavior on Windows in the RTL mode set by default?

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ViewSceneOverlay.java line 53:

> 51:         this.scene = scene;
> 52:         this.painter = painter;
> 53:         this.subscription = Subscription.combine(

should this var be called `subscriptions` then?

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ViewSceneOverlay.java line 55:

> 53:         this.subscription = Subscription.combine(
> 54:             scene.rootProperty().subscribe(this::onSceneRootChanged),
> 55:             scene.effectiveNodeOrientationProperty().subscribe(this::onEffectiveNodeOrientationInvalidated));

side note to @hjohn : 
would it make sense to add a `Subscription.subscribe(Runnable)` method for cases like this?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1921#pullrequestreview-3286140206
PR Review Comment: https://git.openjdk.org/jfx/pull/1921#discussion_r2392418600
PR Review Comment: https://git.openjdk.org/jfx/pull/1921#discussion_r2392424549

From tsayao at openjdk.org  Tue Sep 30 19:03:46 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Sep 2025 19:03:46 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working [v5]
In-Reply-To: <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
 <FgFNdbGeoAyR2FjcluUFBng_vZidl8dHTTfvatlT27k=.04e9770d-8f8c-4ff9-8959-bc679a25df57@github.com>
Message-ID: <ayhrbRvfF03HjvUhlKuuR-0TWj7_RHXMt3PK3EPz7n0=.b52a15c8-ce4e-4ca6-834a-6e971a09bb7b@github.com>

On Sun, 28 Sep 2025 20:05:43 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> The bug report is on Linux Mint which does not use ibus (the gnome default).
>> 
>> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
>> 
>> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
>> 
>> @Glavo: Can you check if Chinese input is still correct?
>> @andzsinszan: Can you check for Japanese?
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore IBUS_ENABLE_SYNC_MODE
>  - Restore IBUS_ENABLE_SYNC_MODE

closing in favor of #1924

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

PR Comment: https://git.openjdk.org/jfx/pull/1922#issuecomment-3353432076

From tsayao at openjdk.org  Tue Sep 30 19:03:47 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Sep 2025 19:03:47 GMT
Subject: Withdrawn: 8367045: [Linux] Dead keys not working
In-Reply-To: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
References: <qNeYtynw5m9K_szx1o04jO9J3C1w1C1ZKn0kV2bS_K4=.88614f68-f19c-4f5e-ada8-8ec347fa6827@github.com>
Message-ID: <8GHnpV2xAQQZZdJ04vCyNazqskKBSRyhXT--q246bts=.c3674fe3-a441-4381-8438-3b9733323b9c@github.com>

On Sun, 28 Sep 2025 13:59:46 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> The bug report is on Linux Mint which does not use ibus (the gnome default).
> 
> With this change, it continues to work on ibus, but also works works without it (on mint) and with fcitx.
> 
> It seems it's correct - but it's weird that it needed those bits before. I would say it's related to  `IBUS_ENABLE_SYNC_MODE` (see [this comment](https://github.com/openjdk/jfx/pull/1080#issuecomment-2412202297) on #1080.), but it seems to be still set to 0 on Ubuntu 24.04.
> 
> @Glavo: Can you check if Chinese input is still correct?
> @andzsinszan: Can you check for Japanese?

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Tue Sep 30 19:50:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Sep 2025 19:50:17 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
 [v2]
In-Reply-To: <Po6bwb1qC8ns2ghRckD0PUZAiSJprb1hBMHwwcCS7eE=.0252b8b6-5c8a-4faa-a713-da346a9efd32@github.com>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
 <Po6bwb1qC8ns2ghRckD0PUZAiSJprb1hBMHwwcCS7eE=.0252b8b6-5c8a-4faa-a713-da346a9efd32@github.com>
Message-ID: <UiFyANiaqn1SWiTv40cZVIIthn-fknZmjdS2bWChml0=.7403dbee-100a-454c-97bd-1ae1be4e97b5@github.com>

On Sun, 27 Jul 2025 18:46:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Currently, the color scheme of a system-decorated stage is as follows:
>> * On Windows, the title bar is always light (even if the OS color scheme is dark).
>> * On macOS and Linux, the title bar is light or dark depending on the OS color scheme.
>> 
>> The expected behavior is that the title bar matches the color scheme of the `Scene`.
>> If an application doesn't specify a color scheme, the title bar color should match the OS color scheme.
>> 
>> This PR fixes the behavior for Windows and macOS, but not for Linux (there's no good way to do that).
>> Depending on how you look at it, this is either a bug fix or an enhancement.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into feature/dark-window-frame
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m
>  - Window decorations adapt to color scheme

The changes look reasonable to me. I left a few comments. I still need to test the enhancement.

Speaking of testing, this causes a failure in one of our closed white-box tests. It's trivial for me to fix it, but it will mean that down the road, when this is ready to go in, we will need to coordinate the timing of the integration with you.

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1269:

> 1267:     static const DWORD DWMWA_USE_IMMERSIVE_DARK_MODE = []() {
> 1268:         DWORD ignored;
> 1269:         DWORD infoSize = GetFileVersionInfoSizeEx(FILE_VER_GET_NEUTRAL, L"dwmapi.dll", &ignored);

Since you are explicitly passing a wide string constant, shouldn't you also explicitly use the `GetFileVersionInfoSizeExW` variant of the function? (and yes, I know we define `/UNICODE` but it still seems cleaner to be explicit in this case).

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1275:

> 1273: 
> 1274:         std::vector<char> buffer(infoSize);
> 1275:         if (!GetFileVersionInfoEx(FILE_VER_GET_NEUTRAL, L"dwmapi.dll", ignored,

Use `GetFileVersionInfoExW`?

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1282:

> 1280:         UINT size = 0;
> 1281:         VS_FIXEDFILEINFO* fileInfo = nullptr;
> 1282:         if (!VerQueryValue(buffer.data(), L"\\", reinterpret_cast<LPVOID*>(&fileInfo), &size)) {

`VerQueryValueW`?

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

PR Review: https://git.openjdk.org/jfx/pull/1845#pullrequestreview-3286069445
PR Review Comment: https://git.openjdk.org/jfx/pull/1845#discussion_r2392367366
PR Review Comment: https://git.openjdk.org/jfx/pull/1845#discussion_r2392369375
PR Review Comment: https://git.openjdk.org/jfx/pull/1845#discussion_r2392389423

From mstrauss at openjdk.org  Tue Sep 30 20:08:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 30 Sep 2025 20:08:55 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
 [v3]
In-Reply-To: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
Message-ID: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com>

> Currently, the color scheme of a system-decorated stage is as follows:
> * On Windows, the title bar is always light (even if the OS color scheme is dark).
> * On macOS and Linux, the title bar is light or dark depending on the OS color scheme.
> 
> The expected behavior is that the title bar matches the color scheme of the `Scene`.
> If an application doesn't specify a color scheme, the title bar color should match the OS color scheme.
> 
> This PR fixes the behavior for Windows and macOS, but not for Linux (there's no good way to do that).
> Depending on how you look at it, this is either a bug fix or an enhancement.

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

 - explicitly use wide string functions
 - Merge branch 'master' into feature/dark-window-frame
 - Merge branch 'master' into feature/dark-window-frame
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m
 - Window decorations adapt to color scheme

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

Changes: https://git.openjdk.org/jfx/pull/1845/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1845&range=02
  Stats: 183 lines in 17 files changed: 171 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1845.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1845/head:pull/1845

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

From duke at openjdk.org  Tue Sep 30 23:31:20 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 30 Sep 2025 23:31:20 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

Pabulaner IV has updated the pull request incrementally with two additional commits since the last revision:

 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1904/files
  - new: https://git.openjdk.org/jfx/pull/1904/files/6afc5b5b..33bc0e2a

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

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

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

From duke at openjdk.org  Tue Sep 30 23:31:22 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Tue, 30 Sep 2025 23:31:22 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v2]
In-Reply-To: <B6FDkt0eQ7u_0LBKq0WAfXtloASbftAGL62p_5KpBtg=.b7c791e5-9c77-49e2-ad96-ecff159cffe4@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <B6FDkt0eQ7u_0LBKq0WAfXtloASbftAGL62p_5KpBtg=.b7c791e5-9c77-49e2-ad96-ecff159cffe4@github.com>
Message-ID: <ayM3yHmHx_gw3_LihNLAbRf9jm_VLUXWWe5yyowDPAY=.1a5c1eb3-a2d0-42cf-b793-f36642a96950@github.com>

On Tue, 23 Sep 2025 15:00:11 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

I have now also added the JFXPanel test, but only for the first of the two tests involving the JFXPanel (so where AWT is initialized first). In the other case AWT won't install a menu bar, since JavaFX was initialized first, so nothing will happen.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3354102145