From mstrauss at openjdk.org Wed Oct 1 04:05:59 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 04:05:59 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: > 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. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: rename field ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1921/files - new: https://git.openjdk.org/jfx/pull/1921/files/065ed8c3..3e412c39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1921&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1921&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 jhendrikx at openjdk.org Wed Oct 1 08:44:14 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 08:44:14 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: > 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)** ... John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add test case ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1879/files - new: https://git.openjdk.org/jfx/pull/1879/files/59b5f287..4a6462fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1879&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1879&range=00-01 Stats: 93 lines in 2 files changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1879.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1879/head:pull/1879 PR: https://git.openjdk.org/jfx/pull/1879 From jhendrikx at openjdk.org Wed Oct 1 08:44:15 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 08:44:15 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management In-Reply-To: <0k9alp09IsIjR19fKEt8Ue56i0HXURNwnyPrRB7Swe8=.7ba4189c-a4e4-43b0-b7fe-09fb5ef06f76@github.com> References: <0k9alp09IsIjR19fKEt8Ue56i0HXURNwnyPrRB7Swe8=.7ba4189c-a4e4-43b0-b7fe-09fb5ef06f76@github.com> Message-ID: On Fri, 5 Sep 2025 15:55:37 GMT, Kevin Rushforth 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 `lo... > > 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. @kevinrushforth I think I managed a suitable unit test. It fails without the fix, and passes with the fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1879#issuecomment-3355326869 From zelmidaoui at openjdk.org Wed Oct 1 12:18:15 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 1 Oct 2025 12:18:15 GMT Subject: RFR: 8368511: Incorrect "Group" name after click on link in JavaFX CSS Reference Guide In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:50:19 GMT, Ziad El Midaoui wrote: > Changed `Group` name to `PopupWindow` in `cssref.html` Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1923#issuecomment-3356039203 From duke at openjdk.org Wed Oct 1 12:20:20 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Oct 2025 12:20:20 GMT Subject: RFR: 8368511: Incorrect "Group" name after click on link in JavaFX CSS Reference Guide In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:50:19 GMT, Ziad El Midaoui wrote: > Changed `Group` name to `PopupWindow` in `cssref.html` @Ziad-Mid Your change (at version 8785b5520313d49fa09f622c25731990635508c7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1923#issuecomment-3356047808 From zelmidaoui at openjdk.org Wed Oct 1 12:24:35 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 1 Oct 2025 12:24:35 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 18:03:54 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> rename field > > 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? I do not have a Linux machine to test it. I am only able to test on mac / win which seems to work fine ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1921#discussion_r2394385158 From zelmidaoui at openjdk.org Wed Oct 1 12:48:54 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 1 Oct 2025 12:48:54 GMT Subject: Integrated: 8368511: Incorrect "Group" name after click on link in JavaFX CSS Reference Guide In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:50:19 GMT, Ziad El Midaoui wrote: > Changed `Group` name to `PopupWindow` in `cssref.html` This pull request has now been integrated. Changeset: 76aba9ae Author: Ziad El Midaoui Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/76aba9ae392b7936648ce6130b143d4aa19049f4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8368511: Incorrect "Group" name after click on link in JavaFX CSS Reference Guide Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1923 From tsayao at openjdk.org Wed Oct 1 12:57:43 2025 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 1 Oct 2025 12:57:43 GMT Subject: RFR: 8367045: [Linux] Dead keys not working In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox wrote: > 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. I'll do some testing, probably this weekend. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1924#issuecomment-3356170561 From angorya at openjdk.org Wed Oct 1 14:37:38 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 14:37:38 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:05:59 GMT, Michael Strau? 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. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename field @kevinrushforth the changes look good and should work equally well on linux, but I feel we still need to verify that. Maybe @lukostyra or @arapte could take a quick look? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1921#pullrequestreview-3289549008 From angorya at openjdk.org Wed Oct 1 14:41:52 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 14:41:52 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: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com> Message-ID: On Sat, 30 Aug 2025 15:46:29 GMT, Nir Lisker 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 Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3289571635 From angorya at openjdk.org Wed Oct 1 14:41:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 14:41:54 GMT Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2] In-Reply-To: References: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com> Message-ID: On Tue, 2 Sep 2025 21:21:07 GMT, Nir Lisker wrote: > I have a future docs change in the works around mouse events that clears up a lot of things. Is it going to be a separate PR or a part of this one? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3356714876 From nlisker at openjdk.org Wed Oct 1 14:48:33 2025 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 1 Oct 2025 14:48:33 GMT Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2] In-Reply-To: References: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com> Message-ID: On Wed, 1 Oct 2025 14:36:51 GMT, Andy Goryachev wrote: > > I have a future docs change in the works around mouse events that clears up a lot of things. > > Is it going to be a separate PR or a part of this one? Separate. It will encompass mouse events and drag events, though I hit an obstacle with testing touch events. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3356785869 From kcr at openjdk.org Wed Oct 1 15:48:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 15:48:41 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 My testing looks good. Suggestion: consider a manual test for this (maybe adding something to MonkeyTester?). We don't have a test program in our repo that sets `Scene.Preference.colorScheme`. This is pending a second reviewer. @mstr2 I have updated our closed whitebox test as mentioned above, so it will be ready to go in when your PR is ready. Check with me as to the timing of integrating this. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1845#pullrequestreview-3289880092 PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357037624 From angorya at openjdk.org Wed Oct 1 15:58:15 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 15:58:15 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> On Wed, 1 Oct 2025 08:44:14 GMT, John Hendrikx 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 `lo... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java line 646: > 644: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(level2)); > 645: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(leaf)); > 646: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(sibling)); Excellent test, thank you! Question: When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395101793 From mstrauss at openjdk.org Wed Oct 1 16:10:54 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 16:10:54 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Wed, 1 Oct 2025 15:43:41 GMT, Kevin Rushforth wrote: > My testing looks good. > > Suggestion: consider a manual test for this (maybe adding something to MonkeyTester?). We don't have a test program in our repo that sets `Scene.Preference.colorScheme`. I was planning to do something like this for [System Colors](https://gist.github.com/mstr2/afac42ab9587c1040a6cf7b091cee99f) on the CSS features arc, which includes all kinds of color-related system properties. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357117213 From angorya at openjdk.org Wed Oct 1 16:14:48 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 16:14:48 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Wed, 1 Oct 2025 16:08:09 GMT, Michael Strau? wrote: > Suggestion: consider a manual test for this (maybe adding something to MonkeyTester?). We don't have a test program in our repo that sets `Scene.Preference.colorScheme`. This could be added to the `StagePage` there (I know there is a Stage Tester tool, but it does not remember user choices and probably can be replaced with the `StagePage`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357130657 From kcr at openjdk.org Wed Oct 1 16:26:41 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 16:26:41 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:44:14 GMT, John Hendrikx 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 `lo... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case LGTM. I confirm that the new test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1879#pullrequestreview-3290031236 From kcr at openjdk.org Wed Oct 1 16:26:43 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 16:26:43 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> Message-ID: <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> On Wed, 1 Oct 2025 15:55:11 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java line 646: > >> 644: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(level2)); >> 645: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(leaf)); >> 646: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(sibling)); > > Excellent test, thank you! > > Question: > When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? > The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? This is already the case irrespective of this PR. The point of this PR is to ensure that the flags are consistently set as to which part(s) of the scene graph are dirty and need to be reevaluated for the next layout pass. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395172710 From kcr at openjdk.org Wed Oct 1 16:27:40 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 16:27:40 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:05:59 GMT, Michael Strau? 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. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename field I can do a quick test of this on Linux (Ubuntu 24.04). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1921#issuecomment-3357180667 From angorya at openjdk.org Wed Oct 1 16:33:48 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 16:33:48 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:44:14 GMT, John Hendrikx 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 `lo... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case Marked as reviewed by angorya (Reviewer). modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1077: > 1075: */ > 1076: > 1077: p.requestLayout(forceParentLayout); very, very minor suggestion to makes it more compact (it's ok to leave things as is): // The forceParentLayout flag must be propagated to mark all ancestors // as needing layout. Failure to do so while performingLayout is true // would stop the propagation mid-tree. This leaves some nodes as needing // layout, while its ancestors are clean, which is an inconsistent state. p.requestLayout(forceParentLayout); ------------- PR Review: https://git.openjdk.org/jfx/pull/1879#pullrequestreview-3290055086 PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395189222 From mstrauss at openjdk.org Wed Oct 1 16:33:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 16:33:50 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:24:06 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/ParentTest.java line 646: >> >>> 644: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(level2)); >>> 645: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(leaf)); >>> 646: assertEquals(LayoutFlags.CLEAN, ParentShim.getLayoutFlag(sibling)); >> >> Excellent test, thank you! >> >> Question: >> When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? >> The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? > > This is already the case irrespective of this PR. The point of this PR is to ensure that the flags are consistently set as to which part(s) of the scene graph are dirty and need to be reevaluated for the next layout pass. We should probably resurrect #433 at some point. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395189255 From angorya at openjdk.org Wed Oct 1 16:39:53 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 16:39:53 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:31:08 GMT, Michael Strau? wrote: >> This is already the case irrespective of this PR. The point of this PR is to ensure that the flags are consistently set as to which part(s) of the scene graph are dirty and need to be reevaluated for the next layout pass. > > We should probably resurrect #433 at some point. Or maybe even make it more generic: detect when (a small number of) additional layout passes are needed and do them right away instead of waiting for another pulse? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395202205 From mstrauss at openjdk.org Wed Oct 1 16:49:06 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 16:49:06 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:37:07 GMT, Andy Goryachev wrote: >> We should probably resurrect #433 at some point. > > Or maybe even make it more generic: detect when (a small number of) additional layout passes are needed and do them right away instead of waiting for another pulse? That's exactly what this old PR does. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395210254 From jhendrikx at openjdk.org Wed Oct 1 16:49:06 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 16:49:06 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:40:34 GMT, Michael Strau? wrote: >> Or maybe even make it more generic: detect when (a small number of) additional layout passes are needed and do them right away instead of waiting for another pulse? > > That's exactly what this old PR does. > When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? Well, if layout runs (due to a significant change), you'll see components be re-arranged, and if a 2nd pulse is needed, you would probably not notice as things were moved around a lot anyway. But on top of that, there is a good chance the 2nd pass is just recalculating everything without actually changing anything because it is often triggered without a good reason. For example: Take an HBox for example. During layoutChildren, it will position its children. If this involves moving a child to the right or left because an earlier child has shrunk/grown then layout X is changed and triggers the logic in Node (without good reason I might add). This is in part because HBox does not update or set the "current layout child" at all (none of the containers do this, except Parent's layoutChildren which is almost always overridden). So this code below in Node will trigger and force another layout pass: if (p != null && !p.isCurrentLayoutChild(Node.this)) { if (isManaged()) { // Force its parent to fix the layout since it is a managed child. p.requestLayout(true); } else { // Parent size changed, parent's parent might need to re-layout p.clearSizeCache(); p.requestParentLayout(); } } All the ingredients match: - LayoutX was modified on a child - Its parent is not `null` (it's the HBox) - It is not the current layout child (HBox doesn't update this before modifying a position on a child) - The child in question is managed (all children in an HBox generally are) End result: schedule another layout pass Now, if in the 2nd pass none of the X (or Y) positions change again, then this 2nd pass will end up doing nothing. Quite wasteful. > The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? Calling `layout` won't do much when the flags are bad, as layout basically operates based on those flags. So if you call layout at the root, and the flags say that it is `CLEAN` then it stops right there. However there are many things that will "fix" the situation; this can be a nearby Node that changes size for some reason, or say the user resizing the Window. Generally, you will almost never notice as often something triggers layout again, fixing the flags, but if say a custom control is careful about when to redo calculations (because they're even more expensive than usual) and uses tricks like `setNeedsLayout(true)` then a part of the UI may not get updated as you'd expect as the flags got into a bad state. Also see the long note on top of this PR.... the way the flags are managed, and the way that Parent allows `requestLayout` to be overridden by children (really bad design there), it is still possible to mess up the flags. All this PR does is remove one of the ways (I'd remove the other way as well, but it would mean making `requestLayout` final). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395215058 From jhendrikx at openjdk.org Wed Oct 1 16:53:30 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 16:53:30 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 16:31:14 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > Marked as reviewed by angorya (Reviewer). Thanks for the quick reviews @andy-goryachev-oracle @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1879#issuecomment-3357260334 From angorya at openjdk.org Wed Oct 1 16:53:32 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 16:53:32 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:44:14 GMT, John Hendrikx 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 `lo... > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case sorry for the long delay... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1879#issuecomment-3357263492 From jhendrikx at openjdk.org Wed Oct 1 16:57:30 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 16:57:30 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:42:42 GMT, John Hendrikx wrote: >> That's exactly what this old PR does. > >> When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? > > Well, if layout runs (due to a significant change), you'll see components be re-arranged, and if a 2nd pulse is needed, you would probably not notice as things were moved around a lot anyway. But on top of that, there is a good chance the 2nd pass is just recalculating everything without actually changing anything because it is often triggered without a good reason. For example: > > Take an HBox for example. During layoutChildren, it will position its children. If this involves moving a child to the right or left because an earlier child has shrunk/grown then layout X is changed and triggers the logic in Node (without good reason I might add). This is in part because HBox does not update or set the "current layout child" at all (none of the containers do this, except Parent's layoutChildren which is almost always overridden). So this code below in Node will trigger and force another layout pass: > > if (p != null && !p.isCurrentLayoutChild(Node.this)) { > if (isManaged()) { > // Force its parent to fix the layout since it is a managed child. > p.requestLayout(true); > } else { > // Parent size changed, parent's parent might need to re-layout > p.clearSizeCache(); > p.requestParentLayout(); > } > } > > All the ingredients match: > - LayoutX was modified on a child > - Its parent is not `null` (it's the HBox) > - It is not the current layout child (HBox doesn't update this before modifying a position on a child) > - The child in question is managed (all children in an HBox generally are) > > End result: schedule another layout pass > > Now, if in the 2nd pass none of the X (or Y) positions change again, then this 2nd pass will end up doing nothing. Quite wasteful. > >> The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? > > Calling `layout` won't do much when the flags are bad, as layout basically operates based on those flags. So if you call layout at the root, and the flags say that it is `CLEAN` then it stops right there. > > However there are many things that will "fix" the situation; this can be a nearby Node t... > Or maybe even make it more generic: detect when (a small number of) additional layout passes are needed and do them right away instead of waiting for another pulse? But also avoid passes that are not needed... I mean HBox almost always triggering a redundant 2nd pass makes the logic in `Node` suspect IMHO. I get why the logic is **really** there; a user may modify layoutX randomly on some managed control outside a layout pass; in that case you do want the Parent that is managing those nodes to take control and "fix" what the user broke, but it is triggering much more often than needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395250606 From angorya at openjdk.org Wed Oct 1 17:14:08 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 17:14:08 GMT Subject: RFR: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management [v2] In-Reply-To: References: <9u7XNJq6u75j49obq5vBUhvE06PlUbqiKO0MD1vQgmw=.36ee1799-0c42-4721-8d35-1e6de57aa31c@github.com> <0ArOe3VJ6CBdO_Dvy4slvjjLjH8EEmAbTP2RbYBW-NE=.4138a0f0-e0bc-4290-89a3-2292c3cf6432@github.com> Message-ID: On Wed, 1 Oct 2025 16:55:00 GMT, John Hendrikx wrote: >>> When a situation like this happens in reality, we might see a momentary flicker due to the layout spanning several pulses, correct? >> >> Well, if layout runs (due to a significant change), you'll see components be re-arranged, and if a 2nd pulse is needed, you would probably not notice as things were moved around a lot anyway. But on top of that, there is a good chance the 2nd pass is just recalculating everything without actually changing anything because it is often triggered without a good reason. For example: >> >> Take an HBox for example. During layoutChildren, it will position its children. If this involves moving a child to the right or left because an earlier child has shrunk/grown then layout X is changed and triggers the logic in Node (without good reason I might add). This is in part because HBox does not update or set the "current layout child" at all (none of the containers do this, except Parent's layoutChildren which is almost always overridden). So this code below in Node will trigger and force another layout pass: >> >> if (p != null && !p.isCurrentLayoutChild(Node.this)) { >> if (isManaged()) { >> // Force its parent to fix the layout since it is a managed child. >> p.requestLayout(true); >> } else { >> // Parent size changed, parent's parent might need to re-layout >> p.clearSizeCache(); >> p.requestParentLayout(); >> } >> } >> >> All the ingredients match: >> - LayoutX was modified on a child >> - Its parent is not `null` (it's the HBox) >> - It is not the current layout child (HBox doesn't update this before modifying a position on a child) >> - The child in question is managed (all children in an HBox generally are) >> >> End result: schedule another layout pass >> >> Now, if in the 2nd pass none of the X (or Y) positions change again, then this 2nd pass will end up doing nothing. Quite wasteful. >> >>> The platform itself can't really do anything, except for the application code to call the layout() explicitly to avoid flicker, right? >> >> Calling `layout` won't do much when the flags are bad, as layout basically operates based on those flags. So if you call layout at the root, and the flags say that it is `CLEAN` then it stops right there. >> >> However there are many thi... > >> Or maybe even make it more generic: detect when (a small number of) additional layout passes are needed and do them right away instead of waiting for another pulse? > > But also avoid passes that are not needed... I mean HBox almost always triggering a redundant 2nd pass makes the logic in `Node` suspect IMHO. > > I get why the logic is **really** there; a user may modify layoutX randomly on some managed control outside a layout pass; in that case you do want the Parent that is managing those nodes to take control and "fix" what the user broke, but it is triggering much more often than needed. that was a good, informative discussion, thank you all! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1879#discussion_r2395291017 From kcr at openjdk.org Wed Oct 1 17:18:10 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 17:18:10 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:05:59 GMT, Michael Strau? 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. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename field LGTM. Tested on Linux using MonkeyTester, and verified that it now works as expected with RTL. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1921#pullrequestreview-3290219963 From angorya at openjdk.org Wed Oct 1 17:19:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 17:19:20 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: <0Ub0MtiUNbEIbXJX5miFdG-YjfheWdzP_676WjOEA6s=.2e140826-d362-41ea-8ba2-a7af1b3cd543@github.com> On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 I've added scene preferences to the monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest but for some reason, the DARK color scheme does not show up on my mac when set via properties. Did I do something wrong? https://github.com/andy-goryachev-oracle/MonkeyTest/blob/33702ae9f753a4d4857dbb38258c2e42b61eaecc/src/com/oracle/tools/fx/monkey/pages/StagePage.java#L161 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357345551 From zelmidaoui at openjdk.org Wed Oct 1 17:26:25 2025 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 1 Oct 2025 17:26:25 GMT Subject: RFR: 8368021: Window buttons of extended RTL stage are on the wrong side [v2] In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 04:05:59 GMT, Michael Strau? 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. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > rename field LGTM ------------- Marked as reviewed by zelmidaoui (Author). PR Review: https://git.openjdk.org/jfx/pull/1921#pullrequestreview-3290246051 From mstrauss at openjdk.org Wed Oct 1 17:36:55 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 17:36:55 GMT Subject: Integrated: 8368021: Window buttons of extended RTL stage are on the wrong side In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 04:56:51 GMT, Michael Strau? 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 pull request has now been integrated. Changeset: 52e3d63e Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/52e3d63e95fa9f3c95b39a13ed4f900e7a5c3f34 Stats: 132 lines in 6 files changed: 102 ins; 5 del; 25 mod 8368021: Window buttons of extended RTL stage are on the wrong side Reviewed-by: angorya, kcr, zelmidaoui ------------- PR: https://git.openjdk.org/jfx/pull/1921 From mstrauss at openjdk.org Wed Oct 1 17:40:46 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 17:40:46 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <0Ub0MtiUNbEIbXJX5miFdG-YjfheWdzP_676WjOEA6s=.2e140826-d362-41ea-8ba2-a7af1b3cd543@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> <0Ub0MtiUNbEIbXJX5miFdG-YjfheWdzP_676WjOEA6s=.2e140826-d362-41ea-8ba2-a7af1b3cd543@github.com> Message-ID: On Wed, 1 Oct 2025 17:16:28 GMT, Andy Goryachev wrote: > but for some reason, the DARK color scheme does not show up on my mac when set via properties. Did I do something wrong? It seems like you never read the scene color scheme, you're only setting it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357415137 From mstrauss at openjdk.org Wed Oct 1 17:49:51 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 17:49:51 GMT Subject: [jfx25u] RFR: 8368021: Window buttons of extended RTL stage are on the wrong side Message-ID: Hi all, This pull request contains a backport of commit [52e3d63e](https://github.com/openjdk/jfx/commit/52e3d63e95fa9f3c95b39a13ed4f900e7a5c3f34) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Michael Strau? on 1 Oct 2025 and was reviewed by Andy Goryachev, Kevin Rushforth and Ziad El Midaoui. Thanks! ------------- Commit messages: - Backport 52e3d63e95fa9f3c95b39a13ed4f900e7a5c3f34 Changes: https://git.openjdk.org/jfx25u/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368021 Stats: 132 lines in 6 files changed: 102 ins; 5 del; 25 mod Patch: https://git.openjdk.org/jfx25u/pull/20.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/20/head:pull/20 PR: https://git.openjdk.org/jfx25u/pull/20 From kcr at openjdk.org Wed Oct 1 17:51:20 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 17:51:20 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 FWIW, here is the test program I used to verify this on Windows and macOS. [HelloDarkMode.java](https://github.com/user-attachments/files/22645745/HelloDarkMode.java) The important bit is: scene.getPreferences().setColorScheme(ColorScheme.DARK); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357436294 PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357439466 From angorya at openjdk.org Wed Oct 1 17:51:22 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 17:51:22 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> <0Ub0MtiUNbEIbXJX5miFdG-YjfheWdzP_676WjOEA6s=.2e140826-d362-41ea-8ba2-a7af1b3cd543@github.com> Message-ID: On Wed, 1 Oct 2025 17:38:12 GMT, Michael Strau? wrote: > It seems like you never read the scene color scheme, you're only setting it. The Platform.Preferences are read in L114 to initialize the UI properties, then the Scene.Preferences are set in L162. After I change the option via UI to DARK the window shows up in LIGHT. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357443279 From jhendrikx at openjdk.org Wed Oct 1 17:58:10 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 17:58:10 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v19] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sun, 8 Jun 2025 11:18:51 GMT, John Hendrikx 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 open I suppose. Going for the record here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-3357464021 From jhendrikx at openjdk.org Wed Oct 1 17:59:58 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 1 Oct 2025 17:59:58 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: <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com> Message-ID: On Sat, 30 Aug 2025 15:46:29 GMT, Nir Lisker 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 Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3290358444 From kcr at openjdk.org Wed Oct 1 18:02:11 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 18:02:11 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 I ran the MonkeyTester Andy referred above and it works for me. With the fix, I see a dark title bar when setting Scene.Preferences.colorScheme to DARK and a lighter title bar otherwise. I'm still running on macOS 14 (14.8 to be exact). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357473924 From mstrauss at openjdk.org Wed Oct 1 18:10:50 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 18:10:50 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: <1cngL8fIrTt9wtv_X8KGc9YQ7fH-L_rSAkbgu4koKwE=.4852d78a-039d-470e-ac22-532c7630b2d3@github.com> On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 I checked out the [MonkeyTest](https://github.com/andy-goryachev-oracle/MonkeyTest) repo, and it also works for me on macOS 26. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357507300 From mstrauss at openjdk.org Wed Oct 1 18:14:47 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 18:14:47 GMT Subject: [jfx25u] Integrated: 8368021: Window buttons of extended RTL stage are on the wrong side In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 17:39:01 GMT, Michael Strau? wrote: > Hi all, > > This pull request contains a backport of commit [52e3d63e](https://github.com/openjdk/jfx/commit/52e3d63e95fa9f3c95b39a13ed4f900e7a5c3f34) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Michael Strau? on 1 Oct 2025 and was reviewed by Andy Goryachev, Kevin Rushforth and Ziad El Midaoui. > > Thanks! This pull request has now been integrated. Changeset: 55767ca3 Author: Michael Strau? URL: https://git.openjdk.org/jfx25u/commit/55767ca353da5cce748a9b82ab58725bc57b9e92 Stats: 132 lines in 6 files changed: 102 ins; 5 del; 25 mod 8368021: Window buttons of extended RTL stage are on the wrong side Backport-of: 52e3d63e95fa9f3c95b39a13ed4f900e7a5c3f34 ------------- PR: https://git.openjdk.org/jfx25u/pull/20 From angorya at openjdk.org Wed Oct 1 18:18:00 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 18:18:00 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 rebooted my machine. works as expected on macos 15.7 M1 btw, should the rest of the ui come out in dark mode when `Scene.Preferences.colorSceme=DARK` is set? Screenshot 2025-10-01 at 11 15 06 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357531730 PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357542680 From kcr at openjdk.org Wed Oct 1 18:21:19 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 18:21:19 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v19] In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Wed, 1 Oct 2025 17:55:25 GMT, John Hendrikx wrote: > Keep open I suppose. Going for the record here. (Kevin hangs head in shame) I really must put this on my review queue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-3357562824 From angorya at openjdk.org Wed Oct 1 18:22:17 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 18:22:17 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 - retains app-set dark mode when changing the platform theme - changes the theme when colorScheme=null lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1845#pullrequestreview-3290448480 From mstrauss at openjdk.org Wed Oct 1 18:22:19 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 18:22:19 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Wed, 1 Oct 2025 18:15:16 GMT, Andy Goryachev wrote: > btw, should the rest of the ui come out in dark mode when `Scene.Preferences.colorSceme=DARK` is set? Do you mean the controls? Not for now, because Modena doesn't have a dark variant. But aspirationally, sure. We should continue the discussion of a Modena Dark theme or an entirely new theme. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357567271 From kcr at openjdk.org Wed Oct 1 18:26:21 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 18:26:21 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 > /integrate I guess you missed my earlier comment about coordinating on the timing? I'll get the closed side in ASAP, so it won't actually be a problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357588026 From mstrauss at openjdk.org Wed Oct 1 18:26:22 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 18:26:22 GMT Subject: Integrated: 8362091: Window title bar should reflect scene color scheme In-Reply-To: References: Message-ID: On Sun, 13 Jul 2025 05:11:36 GMT, Michael Strau? 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. This pull request has now been integrated. Changeset: d8835464 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/d88354644e5526f1595b64dd0b731733c36b1d03 Stats: 183 lines in 17 files changed: 171 ins; 0 del; 12 mod 8362091: Window title bar should reflect scene color scheme Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1845 From angorya at openjdk.org Wed Oct 1 18:29:20 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 1 Oct 2025 18:29:20 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 I approved the closed part, ready to go. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357602767 From mstrauss at openjdk.org Wed Oct 1 18:32:17 2025 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Oct 2025 18:32:17 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Wed, 1 Oct 2025 18:23:38 GMT, Kevin Rushforth wrote: > I guess you missed my earlier comment about coordinating on the timing? I'll get the closed side in ASAP, so it won't actually be a problem. I read your comment and noted it, but then it somehow slipped my mind. Sorry about that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357613908 From kcr at openjdk.org Wed Oct 1 18:35:23 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 1 Oct 2025 18:35:23 GMT Subject: RFR: 8362091: Window title bar should reflect scene color scheme [v3] In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> References: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com> Message-ID: On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau? 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 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 No worries. I got the closed half in quickly enough that we won't have even a momentary bit of noise in our CI builds. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3357624878 From jhendrikx at openjdk.org Thu Oct 2 08:39:49 2025 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 2 Oct 2025 08:39:49 GMT Subject: Integrated: 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management In-Reply-To: References: Message-ID: On Sat, 23 Aug 2025 14:58:29 GMT, John Hendrikx 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)** ... This pull request has now been integrated. Changeset: 5682424b Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5 Stats: 103 lines in 3 files changed: 101 ins; 0 del; 2 mod 8360940: Layout stops updating when using Parent#setNeedsLayout(true) due to incorrect state management Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1879 From notzed at gmail.com Thu Oct 2 09:59:01 2025 From: notzed at gmail.com (Michael Zucchi) Date: Thu, 2 Oct 2025 19:29:01 +0930 Subject: JDK-8210547[linux] frame pacing etc. In-Reply-To: <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com> References: <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com> Message-ID: All, Unfortunately I'm still unable to login to oracle.com to sign any OCA, so the attached patch is just FYI. It seemed to create my account ok but afterward confirming my email it redirected me to a page without being logged in, and then any attempt to login fails. Firefox 140.x ESR using a default profile of I reserve for finicky sites. Any suggestions? Regardless, I spent a few days poking around including installing ubuntu 24 lts, and building javafx on windows 10 (in a vm) to see what was supposed to be happening. Unlike D3D's SwapChain.Present(flags=0), glXSwapBuffers() is a not a synchronous call[1]. It only inserts a synchronisation point into the command queue which will block any calls that try to render to the back buffer before it is swapped from the front - which means it 'effectively' blocks if there's a backlog, but only at some unknown point in the future (depending on how many buffers the driver sets up). As per [1] and the specification calling glFinish() immediately after glXSwapBuffers() will synchronise to the display and make it behave similarly to D3D's SwapChain.Present(0), but with GLX this only works for a single window. Each additional window adds another whole frame so they all run at 1/N the target rate. I tried a number of approaches, some of them follow. I was focusing on making it work on both a single and multiple window application, and with consistent pulse rates. "vsync" timers -------------- One solution is to change the GtkGlass backend to export a non-zero staticScreen_getVideoRefreshPeriod() which will cause Quantum to assume the clock is accurate to vsync. And then implement something that is either accurate or close-enough. I've tried a few different variations: 0. Use gdk_timeout but use a dynamic timeout each frame based on the reported frame-rate, and using logic to maintain long-term accuracy. Pros: No new mechanisms or races or build changes. Fairly accurate over the lont term. Can adapt if the monitor refresh rate changes at runtime. Avoids vsyncHint() logic. Cons: Jittery due to only millisecond precision and g_mainloop. gdk_monitor_get_refresh_rate() must be correct (and exist) 1. As with the Mac backend, Gtk GlassTimer starts a thread that runs it's own vblank timing. Use a hidden double-buffered Window and call glXSwapBuffer() then glFinish() on a local context before the callback. This works very well for X11 but breaks on XWayland due to [2] where it runs at 'jittery 60Hz' regardless of the actual frame-rate because wayland and by extension Xwayland doesn't think hidden windows should know about vsync. Pros: For X11 Correct and accurate, should be well supported. Avoids vsyncHint() logic. Cons: Requires linking to libGL in gtk3glass. Complicates errors/fallback a bit. gdk_monitor_get_refresh_rate() must be correct (and exist) XWayland is broken. It is unclear whether the timer callback needs to run on the g_mainloop, it doesn't seem to matter. 2. As with the Mac backend, Gtk GlassTimer starts a thread that runs it's own timing. This time using clock_gettime() and usleep() and some logic to avoid drift, handle suspend, and keep consistent frame timing. This works quite well as long as GdkMonitor returns an accurate frame rate. Pros: Simple, not perfect timing but fairly accurate in practice. Avoids syncHint() logic. Could just be implemented in Java if GlassApplication.staticScreen_getVideoRefreshPeriod() is accurate, although a frame-rate might be more useful. Cons: Complicates errors/fallback a bit (if in native) gdk_monitor_get_refresh_rate() must be correct (and exist) It is unclear whether the timer callback needs to run on the g_mainloop, it doesn't seem to matter. glFinish at a different spot ---------------------------- After trying all of the above and reading some more internet forums and articles I tried another approach: run a glFinish() once, after all GlassScene's have been rendered. Pros: Seems to work reliably and accurately. Pretty simple patch that doesn't touch much. Cons: Better Gtk GlassTimer would be nice. Comments -------- A better timer interface and for the animation.pulse value would be nice, perhaps internally fps in decimal fixed-point like GdkMonitor uses. A better Gtk GlassTimer using that, plus GLX syncing after PaintCollector.renderAll(). Just for interest's sake I've attached a WIP patch of the last suggestion. I thought they might provide more insight but I've attached some frame-time plots from the various alternatives anyway. Note that Wayland is on a machine with a frame-rate of 143.88, and the others 59.95. Regards, !Z [1] https://community.khronos.org/t/understanding-the-opengl-main-loop-swapbuffers/75593/12 [2] https://gitlab.freedesktop.org/xorg/xserver/-/issues/631 -------------- next part -------------- A non-text attachment was scrubbed... Name: javafx-vsync.diff Type: text/x-patch Size: 4958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frametimes.png Type: image/png Size: 23375 bytes Desc: not available URL: From kcr at openjdk.org Thu Oct 2 12:15:10 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Oct 2025 12:15:10 GMT Subject: RFR: 8367045: [Linux] Dead keys not working In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox wrote: > 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. @lukostyra Could you be the primary reviewer on this? @tsayao has indicated that we will test (and hopefully review as well). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1924#issuecomment-3360904502 From mariushanl at web.de Thu Oct 2 14:18:29 2025 From: mariushanl at web.de (Marius Hanl) Date: Thu, 2 Oct 2025 14:18:29 +0000 Subject: Aw: JavaFX Direct3D 12 rendering pipeline for Windows In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lukasz.kostyra at oracle.com Thu Oct 2 14:56:43 2025 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Thu, 2 Oct 2025 14:56:43 +0000 Subject: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows In-Reply-To: References: Message-ID: Hi Marius, Thanks for checking! It is difficult to say whether this is still an issue, as that EA build is already a couple months old and I did squash some similar looking bugs since then. We have a new one in the works, but if you don?t want to wait for it you should be able to build the most recent version out of jfx-sandbox repo, ?direct3d12? branch and test this again (on that branch D3D12 builds by default so you shouldn?t have to worry about any additional flags for gradle). If the problem still persists, submitting a JBS issue with a reproducer would be helpful. -Lukasz From: Marius Hanl Sent: Thursday, 2 October 2025 16:18 To: Lukasz Kostyra ; openjfx-dev at openjdk.org Subject: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows Hi Lukasz just tried the build under https://jdk.java.net/javafxdirect3d12/ with some applications (not sure if that is the newest though). Thing look very good, however, I found two issues: When I toggle fullScreen on the primary stage with: stage.setFullScreen(..) , I get an exception (D3D12 swapchain is NULL): java.lang.NullPointerException: D3D12 swapchain is NULL at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.(D3D12SwapChain.java:66) at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.create(D3D12SwapChain.java:78) at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12ResourceFactory.createPresentable(D3D12ResourceFactory.java:338) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:81) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger) at java.base/java.util.concurrent.FutureTask.(FutureTask.java:153) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.RenderJob.(RenderJob.java:45) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.lambda$liveRepaintRenderJob$2(PaintCollector.java:330) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.liveRepaintRenderJob(PaintCollector.java:329) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:810) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:770) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424) at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:850) at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.handleViewEvent(View.java:543) at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.notifyResize(View.java:884) at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinView.notifyResize(WinView.java:91) at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication.lambda$runLoop$0(WinApplication.java:168) at java.base/java.lang.Thread.run(Thread.java:1474) The other problem is related to LineChart. For me, sometimes the lines and the text is not rendered on the x and y axis. When the axis change, it will render them again, but they will always disappear again after resizing the window. Let me know if I should create an issue, or if I should build the branch by myself and test again! :) -- Marius Gesendet: Montag, 14. Oktober 2024 um 17:24 Von: "Lukasz Kostyra" > An: openjfx-dev > Betreff: JavaFX Direct3D 12 rendering pipeline for Windows Hello openjfx-dev, we just pushed a prototype of a new JavaFX Direct3D 12 rendering pipeline for Windows to a new "direct3d12" branch on jfx-sandbox. It is more than an experiment branch - we intend to fully develop the D3D12 backend there. We're not necessarily looking for contributions at this point, but if anyone has early feedback about it or wants to try it by building it themselves, that would be fine. We also did not test it on a wider range of hardware, so your mileage may vary. While D3D12 pipeline will build by default, D3D9 pipeline is still the default pick at runtime. To run anything on D3D12 pipeline you need to force it with ex.: java -Dprism.order=d3d12 ... Backend supports 2D rendering (albeit with some graphical issues here and there that need to be ironed out) and basic 3D rendering. Expect not everything fully working yet (ex. some gradients on 2D controls are incorrect, or 3D-in-2D will straight up not work) and the performance not matching D3D9 yet. Our goal is to first reach feature completion and then focus on performance. Lukasz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Thu Oct 2 15:50:30 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Oct 2025 15:50:30 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 Message-ID: JUnit 6.0.0 is out and we can consider updating to it. Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0 Notes: - Java 17 is the baseline (so not a problem for us, since we have a higher baseline) - Deprecation were removed (not a problem, as we don't rely on any) - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago) JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier. It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable. ------------- Commit messages: - Update to JUnit Version 6.0.0 Changes: https://git.openjdk.org/jfx/pull/1925/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1925&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369049 Stats: 59 lines in 3 files changed: 10 ins; 1 del; 48 mod Patch: https://git.openjdk.org/jfx/pull/1925.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1925/head:pull/1925 PR: https://git.openjdk.org/jfx/pull/1925 From kcr at openjdk.org Thu Oct 2 16:04:45 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Oct 2025 16:04:45 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl wrote: > JUnit 6.0.0 is out and we can consider updating to it. > > Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0 > > Notes: > - Java 17 is the baseline (so not a problem for us, since we have a higher baseline) > - Deprecation were removed (not a problem, as we don't rely on any) > - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago) > > JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier. > > It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable. @Maran23 This requires a new third-party library, which will need approval. Also, I'll need to review the PR. Since you didn't make any changes to the test source code, I presume that JUnit 6 is compatible with 5 (leaving aside the removed deprecations, which don't affect us), unlike the transition from 4 to 5 (version 5 was effectively an entirely new API). I'll take a look at the release notes, but can you summarize the changes you are aware of? Reviewers: @kevinrushforth @arapte @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3361994043 From angorya at openjdk.org Thu Oct 2 16:39:54 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Oct 2025 16:39:54 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl wrote: > JUnit 6.0.0 is out and we can consider updating to it. > > Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0 > > Notes: > - Java 17 is the baseline (so not a problem for us, since we have a higher baseline) > - Deprecation were removed (not a problem, as we don't rely on any) > - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago) > > JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier. > > It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable. This PR changes gradle build only. What about Eclipse and other IDEs? Are they compatible? Are we going to lose the ability to run junit tests from within the IDE? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362109684 From mhanl at openjdk.org Thu Oct 2 16:46:05 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Oct 2025 16:46:05 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 16:01:55 GMT, Kevin Rushforth wrote: > Since you didn't make any changes to the test source code, I presume that JUnit 6 is compatible with 5 (leaving aside the removed deprecations, which don't affect us), unlike the transition from 4 to 5 (version 5 was effectively an entirely new API). Yes, it is completely compatible and I could not spot any problems. Locally, everything works and also the GHA work (did a test run before I made the PR). > I'll take a look at the release notes, but can you summarize the changes you are aware of? Sure! Most of the changes are either removal of deprecated functions or internal changes / dependency changes which we do not use. There is a lot of new functionality for launching test classes / using a custom test engine (we use `junit-jupiter-engine`). We don't do any custom stuff, so we are good here. But for reference, here is more information: https://docs.junit.org/current/user-guide/index.html#launcher-api-launcher-cancellation. One interesting note and addition is: `Stack traces are now pruned up to the test method or lifecycle method`. The result is that the stack trace is slightly shorter, as it does not contain anything before the test method. But for some reason I could not observe that in JavaFX, only another project I did. > `.\gradlew test` Before: ... at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531) at de.abc.def.domain.ExportTriggerTest.testExportTriggerPositive(ExportTriggerTest.java:26) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at java.base/java.util.ArrayList.forEach(ArrayList.java:1604) at java.base/java.util.ArrayList.forEach(ArrayList.java:1604) After: ... at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:158) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:139) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:201) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:152) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:147) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:558) at de.abc.def.domain.ExportTriggerTest.testExportTriggerPositive(ExportTriggerTest.java:26) > This PR changes gradle build only. What about Eclipse and other IDEs? Are they compatible? Are we going to lose the ability to run junit tests from within the IDE? Yes they all are compatible, as nothing really changed when writing tests. Imports are the same, the methods are the same, everything is still compatible. I can also verify that it works in IntelliJ. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362128624 From kevin.rushforth at oracle.com Thu Oct 2 16:59:03 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 2 Oct 2025 09:59:03 -0700 Subject: Using markdown-style javadoc comments (JEP 467) Message-ID: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com> Now that JavaFX requires JDK 24 to build, we can use features from JDK 23 and 24 like markdown javadoc comments from JEP 467 [0], which was delivered in JDK 23. Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have proposed changes that do just that. As was pointed out in a review comment on PR 1873 [3], we should make a deliberate decision to start using them and have some guidelines around doing so. To that end, I would propose that developers can start using markdown javadoc comments in new APIs and in APIs that are modified such that markdown comments would be helpful. This is not an invitation to do wholesale changing of existing javadoc comments to markdown-style comments for docs that otherwise aren't being modified. Comments are welcome. -- Kevin [0] https://openjdk.org/jeps/467 [1] https://github.com/openjdk/jfx/pull/1873 [2] https://github.com/openjdk/jfx/pull/1880 [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713 From andy.goryachev at oracle.com Thu Oct 2 17:10:52 2025 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 2 Oct 2025 17:10:52 +0000 Subject: Using markdown-style javadoc comments (JEP 467) In-Reply-To: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com> References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com> Message-ID: I think it's a good idea, the new markdown style is more readable and compact. The only downside I found so far is that the latest Eclipse does not refresh the javadoc tab when editing (someone said it's already fixed in the mainline). -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Thursday, October 2, 2025 at 09:59 To: openjfx-dev Subject: Using markdown-style javadoc comments (JEP 467) Now that JavaFX requires JDK 24 to build, we can use features from JDK 23 and 24 like markdown javadoc comments from JEP 467 [0], which was delivered in JDK 23. Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have proposed changes that do just that. As was pointed out in a review comment on PR 1873 [3], we should make a deliberate decision to start using them and have some guidelines around doing so. To that end, I would propose that developers can start using markdown javadoc comments in new APIs and in APIs that are modified such that markdown comments would be helpful. This is not an invitation to do wholesale changing of existing javadoc comments to markdown-style comments for docs that otherwise aren't being modified. Comments are welcome. -- Kevin [0] https://openjdk.org/jeps/467 [1] https://github.com/openjdk/jfx/pull/1873 [2] https://github.com/openjdk/jfx/pull/1880 [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Oct 2 17:35:19 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Oct 2025 17:35:19 GMT Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2] In-Reply-To: <7G8Rb7FfNKqLDb8Bz1-dfGtIgOSbkkEfL2aJOWK0ffM=.8ead616b-9b51-4750-b42f-5fa294ad78ef@github.com> References: <7G8Rb7FfNKqLDb8Bz1-dfGtIgOSbkkEfL2aJOWK0ffM=.8ead616b-9b51-4750-b42f-5fa294ad78ef@github.com> Message-ID: On Mon, 1 Sep 2025 21:16:16 GMT, Nir Lisker wrote: >> I think markdown style is ok, since it results in a more readable source. >> >> The support in other tools might be lacking initially (for example, Eclipse does not refresh its javadoc pane with markdown as it does with the usual style) > >> 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. I started a (belated) [discussion on this on the mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2025-October/056578.html). As mentioned in that message, I think using markdown comments is fine for new APIs and docs that are modified in a way that markdown would be helpful. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2399568312 From angorya at openjdk.org Thu Oct 2 17:50:58 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Oct 2025 17:50:58 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl wrote: > JUnit 6.0.0 is out and we can consider updating to it. > > Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0 > > Notes: > - Java 17 is the baseline (so not a problem for us, since we have a higher baseline) > - Deprecation were removed (not a problem, as we don't rely on any) > - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago) > > JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier. > > It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable. I would suggest we postpone the migration to junit6 until after Eclipse provides support for it (screenshot taken with Eclipse Version: 2025-06 (4.36) Build id: I20250528-1830): Screenshot 2025-10-02 at 10 46 25 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362340093 From thiago.sayao at gmail.com Thu Oct 2 18:04:18 2025 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 2 Oct 2025 15:04:18 -0300 Subject: JDK-8210547[linux] frame pacing etc. In-Reply-To: References: <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com> Message-ID: I confess I did not understand much about the problem. Is it about variable refresh rates? If I think a message _VARIABLE_REFRESH is received on the Notify event. Or https://docs.gtk.org/gdk3/class.FrameClock.html I also did an EGL version in place of GLX: https://github.com/openjdk/jfx/pull/1381 -- Thiago Em qui., 2 de out. de 2025 ?s 06:59, Michael Zucchi escreveu: > > All, > > Unfortunately I'm still unable to login to oracle.com to sign any OCA, > so the attached patch is just FYI. It seemed to create my account ok but > afterward confirming my email it redirected me to a page without being > logged in, and then any attempt to login fails. Firefox 140.x ESR using > a default profile of I reserve for finicky sites. Any suggestions? > > Regardless, I spent a few days poking around including installing > ubuntu 24 lts, and building javafx on windows 10 (in a vm) to see what > was supposed to be happening. > > Unlike D3D's SwapChain.Present(flags=0), glXSwapBuffers() is a not a > synchronous call[1]. It only inserts a synchronisation point into the > command queue which will block any calls that try to render to the back > buffer before it is swapped from the front - which means it > 'effectively' blocks if there's a backlog, but only at some unknown > point in the future (depending on how many buffers the driver sets up). > > As per [1] and the specification calling glFinish() immediately after > glXSwapBuffers() will synchronise to the display and make it behave > similarly to D3D's SwapChain.Present(0), but with GLX this only works > for a single window. Each additional window adds another whole frame so > they all run at 1/N the target rate. > > I tried a number of approaches, some of them follow. I was focusing on > making it work on both a single and multiple window application, and > with consistent pulse rates. > > "vsync" timers > -------------- > > One solution is to change the GtkGlass backend to export a non-zero > staticScreen_getVideoRefreshPeriod() which will cause Quantum to > assume the clock is accurate to vsync. And then implement something > that is either accurate or close-enough. > > I've tried a few different variations: > > 0. Use gdk_timeout but use a dynamic timeout each frame based on the > reported frame-rate, and using logic to maintain long-term > accuracy. > > Pros: No new mechanisms or races or build changes. > Fairly accurate over the lont term. > Can adapt if the monitor refresh rate changes at runtime. > Avoids vsyncHint() logic. > Cons: Jittery due to only millisecond precision and g_mainloop. > gdk_monitor_get_refresh_rate() must be correct (and exist) > > 1. As with the Mac backend, Gtk GlassTimer starts a thread that runs > it's own vblank timing. Use a hidden double-buffered Window and > call glXSwapBuffer() then glFinish() on a local context before the > callback. > > This works very well for X11 but breaks on XWayland due to [2] where > it runs at 'jittery 60Hz' regardless of the actual frame-rate because > wayland and by extension Xwayland doesn't think hidden windows should > know about vsync. > > Pros: For X11 Correct and accurate, should be well supported. > Avoids vsyncHint() logic. > Cons: Requires linking to libGL in gtk3glass. > Complicates errors/fallback a bit. > gdk_monitor_get_refresh_rate() must be correct (and exist) > XWayland is broken. > It is unclear whether the timer callback needs to run on the > g_mainloop, it doesn't seem to matter. > > 2. As with the Mac backend, Gtk GlassTimer starts a thread that runs > it's own timing. This time using clock_gettime() and usleep() and > some logic to avoid drift, handle suspend, and keep consistent > frame timing. > > This works quite well as long as GdkMonitor returns an accurate frame > rate. > > Pros: Simple, not perfect timing but fairly accurate in practice. > Avoids syncHint() logic. > Could just be implemented in Java if > GlassApplication.staticScreen_getVideoRefreshPeriod() is > accurate, although a frame-rate might be more useful. > Cons: Complicates errors/fallback a bit (if in native) > gdk_monitor_get_refresh_rate() must be correct (and exist) > It is unclear whether the timer callback needs to run on the > g_mainloop, it doesn't seem to matter. > > glFinish at a different spot > ---------------------------- > > After trying all of the above and reading some more internet forums and > articles I tried another approach: run a glFinish() once, after all > GlassScene's have been rendered. > > Pros: Seems to work reliably and accurately. > Pretty simple patch that doesn't touch much. > Cons: Better Gtk GlassTimer would be nice. > > Comments > -------- > > A better timer interface and for the animation.pulse value would be > nice, perhaps internally fps in decimal fixed-point like GdkMonitor > uses. A better Gtk GlassTimer using that, plus GLX syncing after > PaintCollector.renderAll(). > > Just for interest's sake I've attached a WIP patch of the last > suggestion. I thought they might provide more insight but I've attached > some frame-time plots from the various alternatives anyway. Note that > Wayland is on a machine with a frame-rate of 143.88, and the others 59.95. > > Regards, > !Z > > > [1] > > https://community.khronos.org/t/understanding-the-opengl-main-loop-swapbuffers/75593/12 > [2] https://gitlab.freedesktop.org/xorg/xserver/-/issues/631 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Thu Oct 2 18:14:04 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Oct 2025 18:14:04 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 17:48:01 GMT, Andy Goryachev wrote: > I would suggest we postpone the migration to junit6 Can you check out this branch and run the tests with the JUnit 5 Option? I'm sure it will work, as again, there is no breaking change here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362412979 From angorya at openjdk.org Thu Oct 2 18:19:01 2025 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 2 Oct 2025 18:19:01 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 18:11:52 GMT, Marius Hanl wrote: > Can you check out this branch and run the tests with the JUnit 5 Option? I can, but what is the point of migration then? The moment someone uses a junit6 feature, the Eclipse project will break. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362429142 From kcr at openjdk.org Thu Oct 2 18:34:02 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 2 Oct 2025 18:34:02 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl wrote: > JUnit 6.0.0 is out and we can consider updating to it. > > Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0 > > Notes: > - Java 17 is the baseline (so not a problem for us, since we have a higher baseline) > - Deprecation were removed (not a problem, as we don't rely on any) > - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago) > > JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier. > > It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable. I also don't see the hurry. Absent a compelling reason to update, we can wait for a while. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362475357 From mhanl at openjdk.org Thu Oct 2 18:55:26 2025 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 2 Oct 2025 18:55:26 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0 In-Reply-To: References: Message-ID: <_F8dTyYMBQk8ibQW3o_6_Vg48bk6iSZR8hQ5J970Eoc=.4c79339e-4506-493b-b057-7b6aac3dcfcd@github.com> On Thu, 2 Oct 2025 18:16:45 GMT, Andy Goryachev wrote: > I can, but what is the point of migration then? The moment someone uses a junit6 feature, the Eclipse project will break. Sure, but I can't think of any new features we might want to use. This should really be treated as a normal dependency update. Not that I think we need to merge this anytime soon (that's why I wrote "consider"), but if Eclipse doesn't have "support" for it in 6 months, I would stop waiting at one point. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3362538071 From nlisker at gmail.com Thu Oct 2 19:05:47 2025 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 2 Oct 2025 22:05:47 +0300 Subject: Using markdown-style javadoc comments (JEP 467) In-Reply-To: References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com> Message-ID: As both referenced pull requests are mine, I'll add that MD docs are especially helpful with regards to code blocks. The combination of {@code} and 
 is cumbersome. {@snippet} is also a good solution here. I've been
using MD comments since JDK 23 and I never found the need to use HTML ones
since, especially when you can still use HTML tags in MD comments, which
are necessary for tables (the MD tables flavor in the JDK can't add the
mandatory alt-text/caption).

Further, I don't see an issue with mixed HTML and MD comments in the same
file/repo, just like with any newer replacements. If a relevant segment of
code changes, the doc comments can be converted with it (and I would argue
that this conversion is always an improvement).

Andy, I use the integration builds of Eclipse. They are stable and contain
the latest fixes so I don't need to wait for the quarterly releases.
Parsing MD docs has been fixed, writing them still entails some annoyances
(issue #1800 in jdt.ui), but it works.

On Thu, Oct 2, 2025 at 8:11?PM Andy Goryachev 
wrote:

> I think it's a good idea, the new markdown style is more readable and
> compact.
>
> The only downside I found so far is that the latest Eclipse does not
> refresh the javadoc tab when editing (someone said it's already fixed in
> the mainline).
>
> -andy
>
> *From: *openjfx-dev  on behalf of Kevin
> Rushforth 
> *Date: *Thursday, October 2, 2025 at 09:59
> *To: *openjfx-dev 
> *Subject: *Using markdown-style javadoc comments (JEP 467)
>
> Now that JavaFX requires JDK 24 to build, we can use features from JDK
> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
> delivered in JDK 23.
>
> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
> proposed changes that do just that.
>
> As was pointed out in a review comment on PR 1873 [3], we should make a
> deliberate decision to start using them and have some guidelines around
> doing so.
>
> To that end, I would propose that developers can start using markdown
> javadoc comments in new APIs and in APIs that are modified such that
> markdown comments would be helpful.
>
> This is not an invitation to do wholesale changing of existing javadoc
> comments to markdown-style comments for docs that otherwise aren't being
> modified.
>
> Comments are welcome.
>
> -- Kevin
>
> [0] https://openjdk.org/jeps/467
> [1] https://github.com/openjdk/jfx/pull/1873
> [2] https://github.com/openjdk/jfx/pull/1880
> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Thu Oct  2 19:44:30 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 2 Oct 2025 19:44:30 +0000
Subject: [External] : Re: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: 
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
 
Message-ID: 

The link to the Eclipse issue: https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/1800

Thank you for filing these bugs, Nir!

-andy

From: Nir Lisker 
Date: Thursday, October 2, 2025 at 12:06
To: Andy Goryachev 
Cc: Kevin Rushforth , openjfx-dev 
Subject: [External] : Re: Using markdown-style javadoc comments (JEP 467)

As both referenced pull requests are mine, I'll add that MD docs are especially helpful with regards to code blocks. The combination of {@code} and 
 is cumbersome. {@snippet} is also a good solution here. I've been using MD comments since JDK 23 and I never found the need to use HTML ones since, especially when you can still use HTML tags in MD comments, which are necessary for tables (the MD tables flavor in the JDK can't add the mandatory alt-text/caption).

Further, I don't see an issue with mixed HTML and MD comments in the same file/repo, just like with any newer replacements. If a relevant segment of code changes, the doc comments can be converted with it (and I would argue that this conversion is always an improvement).

Andy, I use the integration builds of Eclipse. They are stable and contain the latest fixes so I don't need to wait for the quarterly releases. Parsing MD docs has been fixed, writing them still entails some annoyances (issue #1800 in jdt.ui), but it works.

On Thu, Oct 2, 2025 at 8:11?PM Andy Goryachev > wrote:
I think it's a good idea, the new markdown style is more readable and compact.

The only downside I found so far is that the latest Eclipse does not refresh the javadoc tab when editing (someone said it's already fixed in the mainline).

-andy

From: openjfx-dev > on behalf of Kevin Rushforth >
Date: Thursday, October 2, 2025 at 09:59
To: openjfx-dev >
Subject: Using markdown-style javadoc comments (JEP 467)

Now that JavaFX requires JDK 24 to build, we can use features from JDK
23 and 24 like markdown javadoc comments from JEP 467 [0], which was
delivered in JDK 23.

Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
proposed changes that do just that.

As was pointed out in a review comment on PR 1873 [3], we should make a
deliberate decision to start using them and have some guidelines around
doing so.

To that end, I would propose that developers can start using markdown
javadoc comments in new APIs and in APIs that are modified such that
markdown comments would be helpful.

This is not an invitation to do wholesale changing of existing javadoc
comments to markdown-style comments for docs that otherwise aren't being
modified.

Comments are welcome.

-- Kevin

[0] https://openjdk.org/jeps/467
[1] https://github.com/openjdk/jfx/pull/1873
[2] https://github.com/openjdk/jfx/pull/1880
[3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mhanl at openjdk.org  Thu Oct  2 19:47:41 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 2 Oct 2025 19:47:41 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
Message-ID: 

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

Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
 - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1830/files
  - new: https://git.openjdk.org/jfx/pull/1830/files/c9843e79..940f7cbd

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

  Stats: 920876 lines in 10194 files changed: 399713 ins; 396789 del; 124374 mod
  Patch: https://git.openjdk.org/jfx/pull/1830.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1830/head:pull/1830

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

From mhanl at openjdk.org  Thu Oct  2 20:12:10 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 2 Oct 2025 20:12:10 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 19:47:41 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
>  - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

I did some benchmarks and attached them to the description. Results look very good and is expected from what I measured myself when I implemented that. 

Since we do not need to throw away all `TableRow`s and `TableCell`s, and then recreate them, we get a massive boost. Especially when we have many items (-> rows) and many columns. 
If `TableCell`s have special logic, like showing a graphic or styling, this will be even bigger.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3362756336

From mhanl at openjdk.org  Thu Oct  2 20:43:14 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 2 Oct 2025 20:43:14 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
 [v3]
In-Reply-To: <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com>
References: 
 <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com>
Message-ID: 

On Tue, 30 Sep 2025 20:08:55 GMT, Michael Strau?  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 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

Had no time to further check this unfortunately, but did a lot of testing today and found no issues on Windows 11! 
Tested also with an application where I implemented a dark/light mode switch with the new `@media` queries and `prefers-color-scheme`.

https://github.com/user-attachments/assets/48fc2b82-1cbe-4067-a7a2-b21ce3052e7c

As mentioned above, Godot has the same logic as we have in the Windows code, so the Windows part looked good to me.

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

PR Comment: https://git.openjdk.org/jfx/pull/1845#issuecomment-3362898888

From duke at openjdk.org  Thu Oct  2 20:55:06 2025
From: duke at openjdk.org (BlueGoliath)
Date: Thu, 2 Oct 2025 20:55:06 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 2 Oct 2025 20:08:54 GMT, Marius Hanl  wrote:

>> Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
>>  - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells
>
> I did some benchmarks and attached them to the description. Results look very good and is expected from what I measured myself when I implemented that. 
> 
> Since we do not need to throw away all `TableRow`s and `TableCell`s, and then recreate them, we get a massive boost. Especially when we have many items (-> rows) and many columns. 
> If `TableCell`s have special logic, like showing a graphic or styling, this will be even bigger.

@Maran23 Not a developer but I'd just like to say thanks for this. For the longest time I thought it was because of lazy coding on my part(new `ReadOnlyObjectWrapper` instances instead of caching) but it turns out that even if you optimize your code, `TableView`'s `refresh `method *still* performs terribly.

I'd like also to point out that the terrible performance isn't just from having 100s of rows. Comparing the CPU usage difference between viewing many updating `Label`(s) at once vs a single `TableView` shows a CPU usage increase(0.01%-0.03%ish to 0.06%-0.08%ish) on relatively extremely powerful modern hardware with just about a dozen rows. 

But what's even worse is the garbage allocation rate. `TableView` in my application allocates entire MEGABYTES of garbage in an application that has a relatively low garbage allocation rate. This not only results in more GCs but could result in expanding the heap, resulting in more app memory usage.

Can this please get more attention?

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3362988887

From mariushanl at web.de  Thu Oct  2 21:10:33 2025
From: mariushanl at web.de (Marius Hanl)
Date: Thu, 2 Oct 2025 21:10:33 +0000
Subject: Aw: RE: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for
 Windows
In-Reply-To: 
References: 
 
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From nlisker at openjdk.org  Thu Oct  2 23:10:07 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 2 Oct 2025 23:10:07 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: 
 <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
Message-ID: 

On Thu, 4 Sep 2025 01:54:26 GMT, Nir Lisker  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

@hjohn Can you be the 2nd reviewer since you use Eclipse?

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

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

From notzed at gmail.com  Fri Oct  3 03:02:55 2025
From: notzed at gmail.com (Michael Zucchi)
Date: Fri, 3 Oct 2025 12:32:55 +0930
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: 
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
Message-ID: <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>

On 3/10/25 03:34, Thiago Milczarek Say?o wrote:
> I confess I did not understand much about the problem.
>
> Is it about variable refresh rates?
> If I think a message _VARIABLE_REFRESH is received on the Notify event.
>
No, I'm pretty sure I would have mentioned that if it was!

> Or
> https://docs.gtk.org/gdk3/class.FrameClock.html
>
I came across that but as far as I can tell that's only for gtk widget's 
rendering pipeline which isn't relevant, apart from maybe an example of 
how to do it.

> I also did an EGL version in place of GLX:
> https://github.com/openjdk/jfx/pull/1381
>
Fair enough.? I may see if that makes any difference another time, 
although the eglSwapBuffers() man page isn't really any different to the 
glX one and afaict from a quick look at the mesa source it all ends up 
at the same place internally.
> -- Thiago
>

It's a couple of things.

I experience the bug mentioned in the title with a trivial test 
programme (first email to list) and default settings - I get uncapped 
pulses/second on multiple AMD systems - ~600/s on a laptop and ~2000/s 
on a desktop.? It's just burning cpu and battery for no good reason.? 
It's probably due to a bug in mesa or amdgpu exposed due to the way 
javafx swaps around gl contexts.

It's about incorrect assumptions about the behaviour of the GLX api - 
i.e. that glXSwapBuffers() on a double-buffered window will block 
waiting for vsync in the same way Direct3D's Present() with the provided 
flags does.? This is not correct[1], and even when GLX does throttle it 
wont necessarily throttle where expected so that 'vsyncHint()' has any 
meaning.? The man page offers the correction: glFinish(), but that 
doesn't work if executed per-window.

It's also about just poor timing code / api in general. 
gdk_threads_add_timeout_full's man page:

    Note that timeout functions may be delayed, due to the processing of
    other event sources. Thus they should not be relied on for precise
    timing. After each call to the timeout function, the time of the
    next timeout is recalculated based on the current time and the given
    interval (it does not try to ?catch up? time lost in?delays).

There is some messy code to try to account for that looseness when vsync 
(the default) is requested (vsyncHint() and associated), but not 
otherwise.? But even without that the api has such limited precision it 
just doesn't work very well.? i.e. setting prism.vsync=false 
javafx.animation.pulse=60 wont give you even a jittery 60/s pulse rate - 
it will be a jittery higher one.? It seems very low hanging fruit to fix.

 ?Z

[1] 
https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jhendrikx at openjdk.org  Fri Oct  3 05:17:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 3 Oct 2025 05:17:03 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: 
 <2r1bN8eAB47kP2QLBV198784hIY_oQZNjq6SDh8c4iM=.ec2f77e4-e9d8-4884-bcf8-06385ce9d33b@github.com>
Message-ID: 

On Thu, 4 Sep 2025 01:54:26 GMT, Nir Lisker  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

LGTM, this was already bugging me, but didn't realize you had a PR for it out.

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

Marked as reviewed by jhendrikx (Reviewer).

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

From jhendrikx at openjdk.org  Fri Oct  3 05:28:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 3 Oct 2025 05:28:22 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 19:47:41 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
>  - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

I think the changes look good.  I'm a bit confused in the performance table with what is meant with the `50 ms -> 0 ms` in the "after" cases though?

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 368:

> 366:         JMemoryBuddy.assertCollectable(ref);
> 367:     }
> 368: 

Is there another test that verifies that cells are garbage collectable?  For example, in the case where a table / list / tree table becomes smaller visually, I think that it should then perhaps discard some cells that then should be collectable?

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

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3297470172
PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2400825922

From nlisker at openjdk.org  Fri Oct  3 05:32:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 3 Oct 2025 05:32:06 GMT
Subject: Integrated: 8366842: Update the classpath file of the graphics module
In-Reply-To: 
References: 
Message-ID: 

On Wed, 3 Sep 2025 22:14:56 GMT, Nir Lisker  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.

This pull request has now been integrated.

Changeset: 21d9113e
Author:    Nir Lisker 
URL:       https://git.openjdk.org/jfx/commit/21d9113e6015e4c217451e4d937a916b27ba8f7e
Stats:     23 lines in 1 file changed: 15 ins; 3 del; 5 mod

8366842: Update the classpath file of the graphics module

Reviewed-by: angorya, jhendrikx

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

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

From sykora at openjdk.org  Fri Oct  3 09:26:05 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Fri, 3 Oct 2025 09:26:05 GMT
Subject: RFR: 8368691: Update libxml2 to 2.14.6
In-Reply-To: 
References: 
Message-ID: 

On Thu, 25 Sep 2025 12:37:48 GMT, Hima Bindu Meda  wrote:

> Updated libxml2 to v2.14.6. Verified build on all platforms. No issue seen.

All builds ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1920#pullrequestreview-3298193203

From lukasz.kostyra at oracle.com  Fri Oct  3 09:55:50 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 3 Oct 2025 09:55:50 +0000
Subject: JavaFX Direct3D 12 rendering pipeline for Windows
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Thanks for checking. I can reproduce both of those as well. The LineChart bug happens with your code (interestingly not in Ensemble8 examples I checked?) and the fullscreen bug also happens on Ensemble. Filing JBS issues would be helpful, you can set me as an assignee as well.

  > Interestingly, this seems to be a new feature from Direct3D 12? Because before, ALT+ENTER did nothing for me
This is possible. To get a D3D12 device and create a D3D12 swap chain we need to integrate with DXGI which is a ?new" subsystem of Windows (?new? == did not exist when 9.0c was out; I believe it was introduced with Windows Vista and starting from DX10). It is possible DXGI has some integrations that make this behaviour possible.

I didn?t look too deep into fullscreen behaviour, mostly because related system tests we have work perfectly fine on 12. My main worry is that it might clash with something JavaFX expects from switching to full screen, so I guess it?s time to take a closer look :)

-Lukasz



Confidential ? Oracle Internal

From: Marius Hanl 
Date: Thursday, 2 October 2025 at 23:10
To: Lukasz Kostyra 
Cc: openjfx-dev at openjdk.org 
Subject: Aw: RE: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows

Hi Lukasz,

I can reproduce both bugs with the newest version from the sandbox repository.
I created a reproducer, both bugs are very simple to reproduce there

  *   The fullscreen bug: Just press ALT+ENTER, and the window tries to get into fullscreen, fails and the exception is printed.
Interestingly, this seems to be a new feature from Direct3D 12? Because before, ALT+ENTER did nothing for me
(I reimplemented that into an application, thats where I found this problem initially, but found out that this works even without handling ALT+ENTER since Direct3D 12)
  *   The LineChart bug: Just resize the window, the LineChart Axis Text disappears sometimes.
This happens for me even initally in another application. Works on the latest branch without Direct3D 12.

The reproducer:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.chart.LineChart;
import javafx.scene.chart.NumberAxis;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class LineChartBug {
    public static void main(String[] args) {
        Application.launch(FxApp.class, args);
    }
    public static class FxApp extends Application {
        @Override
        public void start(Stage primaryStage) {
            BorderPane root = new BorderPane();
            NumberAxis xAxis = new NumberAxis();
            NumberAxis yAxis = new NumberAxis();
            LineChart lineChart = new LineChart<>(xAxis, yAxis);
            StackPane stackPane = new StackPane(lineChart);
            stackPane.setMaxSize(300, 300);
            root.setCenter(stackPane);
            Scene scene = new Scene(root, 1280, 540);
            primaryStage.setScene(scene);
            primaryStage.show();
        }
    }
}

I can also create 2 tickets if needed. Just let me know!

-- Marius


Gesendet: Donnerstag, 2. Oktober 2025 um 16:56
Von: "Lukasz Kostyra" 
An: "Marius Hanl" 
CC: "openjfx-dev at openjdk.org" 
Betreff: RE: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows
Hi Marius,

Thanks for checking! It is difficult to say whether this is still an issue, as that EA build is already a couple months old and I did squash some similar looking bugs since then.

We have a new one in the works, but if you don?t want to wait for it you should be able to build the most recent version out of jfx-sandbox repo, ?direct3d12? branch and test this again (on that branch D3D12 builds by default so you shouldn?t have to worry about any additional flags for gradle). If the problem still persists, submitting a JBS issue with a reproducer would be helpful.

-Lukasz

From: Marius Hanl 
Sent: Thursday, 2 October 2025 16:18
To: Lukasz Kostyra ; openjfx-dev at openjdk.org
Subject: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows

Hi Lukasz

just tried the build under https://jdk.java.net/javafxdirect3d12/ with some applications (not sure if that is the newest though).
Thing look very good, however, I found two issues:

When I toggle fullScreen on the primary stage with: stage.setFullScreen(..) , I get an exception (D3D12 swapchain is NULL):

java.lang.NullPointerException: D3D12 swapchain is NULL
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.(D3D12SwapChain.java:66)
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.create(D3D12SwapChain.java:78)
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12ResourceFactory.createPresentable(D3D12ResourceFactory.java:338)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:81)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
    at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
    at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
    at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
    at java.base/java.util.concurrent.FutureTask.(FutureTask.java:153)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.RenderJob.(RenderJob.java:45)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.lambda$liveRepaintRenderJob$2(PaintCollector.java:330)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.liveRepaintRenderJob(PaintCollector.java:329)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:810)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:770)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:850)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.handleViewEvent(View.java:543)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.notifyResize(View.java:884)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinView.notifyResize(WinView.java:91)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication.lambda$runLoop$0(WinApplication.java:168)
    at java.base/java.lang.Thread.run(Thread.java:1474)

The other problem is related to LineChart. For me, sometimes the lines and the text is not rendered on the x and y axis.
When the axis change, it will render them again, but they will always disappear again after resizing the window.

Let me know if I should create an issue, or if I should build the branch by myself and test again! :)

-- Marius

Gesendet: Montag, 14. Oktober 2024 um 17:24
Von: "Lukasz Kostyra" >
An: openjfx-dev >
Betreff: JavaFX Direct3D 12 rendering pipeline for Windows
Hello openjfx-dev,

we just pushed a prototype of a new JavaFX Direct3D 12 rendering pipeline
for Windows to a new "direct3d12" branch on jfx-sandbox. It is more than an
experiment branch - we intend to fully develop the D3D12 backend there.

We're not necessarily looking for contributions at this point, but if anyone
has early feedback about it or wants to try it by building it themselves,
that would be fine. We also did not test it on a wider range of hardware, so
your mileage may vary. While D3D12 pipeline will build by default, D3D9
pipeline is still the default pick at runtime. To run anything on D3D12
pipeline you need to force it with ex.:
  java -Dprism.order=d3d12 ...

Backend supports 2D rendering (albeit with some graphical issues here and there
that need to be ironed out) and basic 3D rendering. Expect not everything fully
working yet (ex. some gradients on 2D controls are incorrect, or 3D-in-2D will
straight up not work) and the performance not matching D3D9 yet. Our goal is to
first reach feature completion and then focus on performance.

Lukasz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From arapte at openjdk.org  Fri Oct  3 10:21:08 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 3 Oct 2025 10:21:08 GMT
Subject: RFR: 8368166: Media query should accept multiple rules [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 22 Sep 2025 23:52:21 GMT, Michael Strau?  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

LGTM. Verified that with this change, nested `@media` queries with multiple rules can be provided. Also, the older way of providing the `@media` query separately for each rule also works fine.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1915#pullrequestreview-3298356969

From mstrauss at openjdk.org  Fri Oct  3 10:30:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 3 Oct 2025 10:30:07 GMT
Subject: Integrated: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
Message-ID: 

On Sat, 20 Sep 2025 00:21:16 GMT, Michael Strau?  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.

This pull request has now been integrated.

Changeset: a176dad2
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx/commit/a176dad2a2da9f0fac25c6b0ff2028b49f59a526
Stats:     106 lines in 2 files changed: 79 ins; 19 del; 8 mod

8368166: Media query should accept multiple rules

Reviewed-by: angorya, arapte

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

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

From mstrauss at openjdk.org  Fri Oct  3 10:38:32 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 3 Oct 2025 10:38:32 GMT
Subject: [jfx25u] RFR: 8368166: Media query should accept multiple rules
Message-ID: 

Hi all,

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

The commit being backported was authored by Michael Strau? on 3 Oct 2025 and was reviewed by Andy Goryachev and Ambarish Rapte.

Thanks!

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

Commit messages:
 - Backport a176dad2a2da9f0fac25c6b0ff2028b49f59a526

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

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

From lkostyra at openjdk.org  Fri Oct  3 12:53:12 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 3 Oct 2025 12:53:12 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v66]
In-Reply-To: <5z8hC81nG6p8xKCNZXpqeGgmVG2A5yTnI7wOpv0pyNk=.5542f714-d4f3-476a-8608-0011611c799c@github.com>
References: 
 <5z8hC81nG6p8xKCNZXpqeGgmVG2A5yTnI7wOpv0pyNk=.5542f714-d4f3-476a-8608-0011611c799c@github.com>
Message-ID: 

On Sat, 27 Sep 2025 12:31:19 GMT, Thiago Milczarek Sayao  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.
>
> 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

Looks good. A nice refresh and simplification of the GTK side of JavaFX.

With #1870 all tests work well on both Linux and Windows.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3298808482

From lkostyra at openjdk.org  Fri Oct  3 13:22:24 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 3 Oct 2025 13:22:24 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox  wrote:

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

Looks good, verified on Ubuntu 24.04 with IBus off.

As a side note for other reviewers, disabling IBus according to PR description actually did not (fully) help on my system, I still had to call `ibus exit` in console to fully disable it and get the issue to appear.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1924#pullrequestreview-3298943823

From kcr at openjdk.org  Fri Oct  3 14:40:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 14:40:52 GMT
Subject: [jfx25u] RFR: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 10:28:00 GMT, Michael Strau?  wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a176dad2](https://github.com/openjdk/jfx/commit/a176dad2a2da9f0fac25c6b0ff2028b49f59a526) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 3 Oct 2025 and was reviewed by Andy Goryachev and Ambarish Rapte.
> 
> Thanks!

@mstr2 Since this touches the CSS parser, I want to be extra careful when backporting it. How safe do you think this fix is? Could it affect anything other than `@media` queries? I wonder if it would be better to let it bake in jfx26 for a while (a couple of promoted builds) before backporting it to jfx25u.

@arapte @andy-goryachev-oracle What is your risk assessment?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/21#issuecomment-3365964087

From mhanl at openjdk.org  Fri Oct  3 14:48:48 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 3 Oct 2025 14:48:48 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 3 Oct 2025 05:24:12 GMT, John Hendrikx  wrote:

>> Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
>>  - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 368:
> 
>> 366:         JMemoryBuddy.assertCollectable(ref);
>> 367:     }
>> 368: 
> 
> Is there another test that verifies that cells are garbage collectable?  For example, in the case where a table / list / tree table becomes smaller visually, I think that it should then perhaps discard some cells that then should be collectable?

I think there are some when switching the `TableRow`, as this should remove all old rows and gc them at one point.

Other than that, I think there is no case where we gc cells. When we change the viewport width/height, all rows (cells if a `fixedCellSize` is set) will be piled / cached, but not destroyed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2402229185

From mhanl at openjdk.org  Fri Oct  3 14:52:02 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 3 Oct 2025 14:52:02 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 3 Oct 2025 05:25:39 GMT, John Hendrikx  wrote:

> I think the changes look good. I'm a bit confused in the performance table with what is meant with the `50 ms -> 0 ms` in the "after" cases though?

Every `refresh()` will trigger 2 layouts for some reason, where the second one does nothing as nothing is dirty, so basically a noop. I can have a look into that (maybe as a follow up?) but I remember that this happens sometimes in general for the `VirtualFlow` and we should check that generally at one point. 

@andy-goryachev-oracle solved that problem in the `RichTextArea` by isolating the method which should be called e.g. two times (due to e.g. `ScrollBar`s) instead of a real relayout.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3366012168

From angorya at openjdk.org  Fri Oct  3 14:52:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 3 Oct 2025 14:52:53 GMT
Subject: [jfx25u] RFR: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 10:28:00 GMT, Michael Strau?  wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a176dad2](https://github.com/openjdk/jfx/commit/a176dad2a2da9f0fac25c6b0ff2028b49f59a526) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 3 Oct 2025 and was reviewed by Andy Goryachev and Ambarish Rapte.
> 
> Thanks!

I think the risk is low and this PR does address an important issue.  I would backport it.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/21#issuecomment-3366016344

From mstrauss at openjdk.org  Fri Oct  3 15:19:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 3 Oct 2025 15:19:00 GMT
Subject: [jfx25u] RFR: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 3 Oct 2025 14:38:19 GMT, Kevin Rushforth  wrote:

> @mstr2 Since this touches the CSS parser, I want to be extra careful when backporting it. How safe do you think this fix is? Could it affect anything other than `@media` queries?

The code path is not hit unless you have at least one media query. I think the biggest risk is not with well-formed stylesheets, but potentially different parsing behavior for malformed stylesheets (what was broken before, could now be broken differently). But in total, the risk seems rather low.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/21#issuecomment-3366139927

From mariushanl at web.de  Fri Oct  3 15:36:13 2025
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 3 Oct 2025 15:36:13 +0000
Subject: JavaFX Direct3D 12 rendering pipeline for Windows
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Fri Oct  3 15:33:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 15:33:15 GMT
Subject: [jfx25u] RFR: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 10:28:00 GMT, Michael Strau?  wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a176dad2](https://github.com/openjdk/jfx/commit/a176dad2a2da9f0fac25c6b0ff2028b49f59a526) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 3 Oct 2025 and was reviewed by Andy Goryachev and Ambarish Rapte.
> 
> Thanks!

Thanks for the additional info. Approved to backport.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/21#issuecomment-3366195818

From thiago.sayao at gmail.com  Fri Oct  3 15:50:35 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 3 Oct 2025 12:50:35 -0300
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
 <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
Message-ID: 

Just out of curiosity, I compiled the EGL version. Here:
https://github.com/tsayao/jfx/releases/tag/test-egl

It does seem to have a difference in frame rate.



Em sex., 3 de out. de 2025 ?s 00:03, Michael Zucchi 
escreveu:

> On 3/10/25 03:34, Thiago Milczarek Say?o wrote:
>
> I confess I did not understand much about the problem.
>
> Is it about variable refresh rates?
> If I think a message _VARIABLE_REFRESH is received on the Notify event.
>
> No, I'm pretty sure I would have mentioned that if it was!
>
> Or
> https://docs.gtk.org/gdk3/class.FrameClock.html
>
> I came across that but as far as I can tell that's only for gtk widget's
> rendering pipeline which isn't relevant, apart from maybe an example of how
> to do it.
>
> I also did an EGL version in place of GLX:
> https://github.com/openjdk/jfx/pull/1381
>
> Fair enough.  I may see if that makes any difference another time,
> although the eglSwapBuffers() man page isn't really any different to the
> glX one and afaict from a quick look at the mesa source it all ends up at
> the same place internally.
>
> -- Thiago
>
>
> It's a couple of things.
>
> I experience the bug mentioned in the title with a trivial test programme
> (first email to list) and default settings - I get uncapped pulses/second
> on multiple AMD systems - ~600/s on a laptop and ~2000/s on a desktop.
> It's just burning cpu and battery for no good reason.  It's probably due to
> a bug in mesa or amdgpu exposed due to the way javafx swaps around gl
> contexts.
>
> It's about incorrect assumptions about the behaviour of the GLX api - i.e.
> that glXSwapBuffers() on a double-buffered window will block waiting for
> vsync in the same way Direct3D's Present() with the provided flags does.
> This is not correct[1], and even when GLX does throttle it wont necessarily
> throttle where expected so that 'vsyncHint()' has any meaning.  The man
> page offers the correction: glFinish(), but that doesn't work if executed
> per-window.
>
> It's also about just poor timing code / api in general.
> gdk_threads_add_timeout_full's man page:
>
> Note that timeout functions may be delayed, due to the processing of other
> event sources. Thus they should not be relied on for precise timing. After
> each call to the timeout function, the time of the next timeout is
> recalculated based on the current time and the given interval (it does not
> try to ?catch up? time lost in delays).
>
> There is some messy code to try to account for that looseness when vsync
> (the default) is requested (vsyncHint() and associated), but not
> otherwise.  But even without that the api has such limited precision it
> just doesn't work very well.  i.e. setting prism.vsync=false
> javafx.animation.pulse=60 wont give you even a jittery 60/s pulse rate - it
> will be a jittery higher one.  It seems very low hanging fruit to fix.
>
>  Z
>
> [1]
> https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From thiago.sayao at gmail.com  Fri Oct  3 15:55:08 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 3 Oct 2025 12:55:08 -0300
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
 <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
Message-ID: 

On X11GLFactory.c

Around line 92 on setGLXAttrs, add:

glxAttrs[index++] = GLX_CONFIG_CAVEAT;
glxAttrs[index++] = None;

It does seem to fix the problem.


Em sex., 3 de out. de 2025 ?s 00:03, Michael Zucchi 
escreveu:

> On 3/10/25 03:34, Thiago Milczarek Say?o wrote:
>
> I confess I did not understand much about the problem.
>
> Is it about variable refresh rates?
> If I think a message _VARIABLE_REFRESH is received on the Notify event.
>
> No, I'm pretty sure I would have mentioned that if it was!
>
> Or
> https://docs.gtk.org/gdk3/class.FrameClock.html
>
> I came across that but as far as I can tell that's only for gtk widget's
> rendering pipeline which isn't relevant, apart from maybe an example of how
> to do it.
>
> I also did an EGL version in place of GLX:
> https://github.com/openjdk/jfx/pull/1381
>
> Fair enough.  I may see if that makes any difference another time,
> although the eglSwapBuffers() man page isn't really any different to the
> glX one and afaict from a quick look at the mesa source it all ends up at
> the same place internally.
>
> -- Thiago
>
>
> It's a couple of things.
>
> I experience the bug mentioned in the title with a trivial test programme
> (first email to list) and default settings - I get uncapped pulses/second
> on multiple AMD systems - ~600/s on a laptop and ~2000/s on a desktop.
> It's just burning cpu and battery for no good reason.  It's probably due to
> a bug in mesa or amdgpu exposed due to the way javafx swaps around gl
> contexts.
>
> It's about incorrect assumptions about the behaviour of the GLX api - i.e.
> that glXSwapBuffers() on a double-buffered window will block waiting for
> vsync in the same way Direct3D's Present() with the provided flags does.
> This is not correct[1], and even when GLX does throttle it wont necessarily
> throttle where expected so that 'vsyncHint()' has any meaning.  The man
> page offers the correction: glFinish(), but that doesn't work if executed
> per-window.
>
> It's also about just poor timing code / api in general.
> gdk_threads_add_timeout_full's man page:
>
> Note that timeout functions may be delayed, due to the processing of other
> event sources. Thus they should not be relied on for precise timing. After
> each call to the timeout function, the time of the next timeout is
> recalculated based on the current time and the given interval (it does not
> try to ?catch up? time lost in delays).
>
> There is some messy code to try to account for that looseness when vsync
> (the default) is requested (vsyncHint() and associated), but not
> otherwise.  But even without that the api has such limited precision it
> just doesn't work very well.  i.e. setting prism.vsync=false
> javafx.animation.pulse=60 wont give you even a jittery 60/s pulse rate - it
> will be a jittery higher one.  It seems very low hanging fruit to fix.
>
>  Z
>
> [1]
> https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lukasz.kostyra at oracle.com  Fri Oct  3 15:55:45 2025
From: lukasz.kostyra at oracle.com (Lukasz Kostyra)
Date: Fri, 3 Oct 2025 15:55:45 +0000
Subject: JavaFX Direct3D 12 rendering pipeline for Windows
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

Thanks for filing those and for checking! I?ll take a closer look at them in coming days.

> FYI: The ALT+ENTER fullscreen behavior really comes from DXGI. This behavior can also be disabled.
Good catch. We might end up disabling the DXGI full screen shortcut as well to match the behavior with D3D9.

-Lukasz

From: Marius Hanl 
Sent: Friday, 3 October 2025 17:36
To: Lukasz Kostyra 
Cc: openjfx-dev at openjdk.org
Subject: [External] : RE: RE: JavaFX Direct3D 12 rendering pipeline for Windows

Hi Lukasz,

created:

  *   https://bugs.openjdk.org/browse/JDK-8369116 (LineChart)
  *   https://bugs.openjdk.org/browse/JDK-8369117 (Fullscreen)
FYI: The ALT+ENTER fullscreen behavior really comes from DXGI. This behavior can also be disabled. Godot does it here:
https://github.com/godotengine/godot/blob/master/drivers/d3d12/rendering_device_driver_d3d12.cpp#L2852

Also noted that in the ticket!
And thank your for working on Direct3D12!

-- Marius

Gesendet: Freitag, 3. Oktober 2025 um 11:55
Von: "Lukasz Kostyra" >
An: "Marius Hanl" >
CC: "openjfx-dev at openjdk.org" >
Betreff: RE: JavaFX Direct3D 12 rendering pipeline for Windows
Thanks for checking. I can reproduce both of those as well. The LineChart bug happens with your code (interestingly not in Ensemble8 examples I checked?) and the fullscreen bug also happens on Ensemble. Filing JBS issues would be helpful, you can set me as an assignee as well.

  > Interestingly, this seems to be a new feature from Direct3D 12? Because before, ALT+ENTER did nothing for me
This is possible. To get a D3D12 device and create a D3D12 swap chain we need to integrate with DXGI which is a ?new" subsystem of Windows (?new? == did not exist when 9.0c was out; I believe it was introduced with Windows Vista and starting from DX10). It is possible DXGI has some integrations that make this behaviour possible.

I didn?t look too deep into fullscreen behaviour, mostly because related system tests we have work perfectly fine on 12. My main worry is that it might clash with something JavaFX expects from switching to full screen, so I guess it?s time to take a closer look :)

-Lukasz



From: Marius Hanl >
Date: Thursday, 2 October 2025 at 23:10
To: Lukasz Kostyra >
Cc: openjfx-dev at openjdk.org >
Subject: Aw: RE: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows
Hi Lukasz,

I can reproduce both bugs with the newest version from the sandbox repository.
I created a reproducer, both bugs are very simple to reproduce there

  *   The fullscreen bug: Just press ALT+ENTER, and the window tries to get into fullscreen, fails and the exception is printed.
Interestingly, this seems to be a new feature from Direct3D 12? Because before, ALT+ENTER did nothing for me
(I reimplemented that into an application, thats where I found this problem initially, but found out that this works even without handling ALT+ENTER since Direct3D 12)
  *   The LineChart bug: Just resize the window, the LineChart Axis Text disappears sometimes.
This happens for me even initally in another application. Works on the latest branch without Direct3D 12.
The reproducer:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.chart.LineChart;
import javafx.scene.chart.NumberAxis;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class LineChartBug {
    public static void main(String[] args) {
        Application.launch(FxApp.class, args);
    }
    public static class FxApp extends Application {
        @Override
        public void start(Stage primaryStage) {
            BorderPane root = new BorderPane();
            NumberAxis xAxis = new NumberAxis();
            NumberAxis yAxis = new NumberAxis();
            LineChart lineChart = new LineChart<>(xAxis, yAxis);
            StackPane stackPane = new StackPane(lineChart);
            stackPane.setMaxSize(300, 300);
            root.setCenter(stackPane);
            Scene scene = new Scene(root, 1280, 540);
            primaryStage.setScene(scene);
            primaryStage.show();
        }
    }
}

I can also create 2 tickets if needed. Just let me know!

-- Marius


Gesendet: Donnerstag, 2. Oktober 2025 um 16:56
Von: "Lukasz Kostyra" >
An: "Marius Hanl" >
CC: "openjfx-dev at openjdk.org" >
Betreff: RE: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows
Hi Marius,

Thanks for checking! It is difficult to say whether this is still an issue, as that EA build is already a couple months old and I did squash some similar looking bugs since then.

We have a new one in the works, but if you don?t want to wait for it you should be able to build the most recent version out of jfx-sandbox repo, ?direct3d12? branch and test this again (on that branch D3D12 builds by default so you shouldn?t have to worry about any additional flags for gradle). If the problem still persists, submitting a JBS issue with a reproducer would be helpful.

-Lukasz

From: Marius Hanl >
Sent: Thursday, 2 October 2025 16:18
To: Lukasz Kostyra >; openjfx-dev at openjdk.org
Subject: [External] : Aw: JavaFX Direct3D 12 rendering pipeline for Windows

Hi Lukasz

just tried the build under https://jdk.java.net/javafxdirect3d12/ with some applications (not sure if that is the newest though).
Thing look very good, however, I found two issues:

When I toggle fullScreen on the primary stage with: stage.setFullScreen(..) , I get an exception (D3D12 swapchain is NULL):

java.lang.NullPointerException: D3D12 swapchain is NULL
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.(D3D12SwapChain.java:66)
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12SwapChain.create(D3D12SwapChain.java:78)
    at javafx.graphics at 25-direct3d12/com.sun.prism.d3d12.D3D12ResourceFactory.createPresentable(D3D12ResourceFactory.java:338)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:81)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
    at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369)
    at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
    at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
    at java.base/java.util.concurrent.FutureTask.(FutureTask.java:153)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.RenderJob.(RenderJob.java:45)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.lambda$liveRepaintRenderJob$2(PaintCollector.java:330)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.PaintCollector.liveRepaintRenderJob(PaintCollector.java:329)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:810)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler$ViewEventNotification.get(GlassViewEventHandler.java:770)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
    at javafx.graphics at 25-direct3d12/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:850)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.handleViewEvent(View.java:543)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.View.notifyResize(View.java:884)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinView.notifyResize(WinView.java:91)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
    at javafx.graphics at 25-direct3d12/com.sun.glass.ui.win.WinApplication.lambda$runLoop$0(WinApplication.java:168)
    at java.base/java.lang.Thread.run(Thread.java:1474)

The other problem is related to LineChart. For me, sometimes the lines and the text is not rendered on the x and y axis.
When the axis change, it will render them again, but they will always disappear again after resizing the window.

Let me know if I should create an issue, or if I should build the branch by myself and test again! :)

-- Marius

Gesendet: Montag, 14. Oktober 2024 um 17:24
Von: "Lukasz Kostyra" >
An: openjfx-dev >
Betreff: JavaFX Direct3D 12 rendering pipeline for Windows
Hello openjfx-dev,

we just pushed a prototype of a new JavaFX Direct3D 12 rendering pipeline
for Windows to a new "direct3d12" branch on jfx-sandbox. It is more than an
experiment branch - we intend to fully develop the D3D12 backend there.

We're not necessarily looking for contributions at this point, but if anyone
has early feedback about it or wants to try it by building it themselves,
that would be fine. We also did not test it on a wider range of hardware, so
your mileage may vary. While D3D12 pipeline will build by default, D3D9
pipeline is still the default pick at runtime. To run anything on D3D12
pipeline you need to force it with ex.:
  java -Dprism.order=d3d12 ...

Backend supports 2D rendering (albeit with some graphical issues here and there
that need to be ironed out) and basic 3D rendering. Expect not everything fully
working yet (ex. some gradients on 2D controls are incorrect, or 3D-in-2D will
straight up not work) and the performance not matching D3D9 yet. Our goal is to
first reach feature completion and then focus on performance.

Lukasz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Fri Oct  3 16:19:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 3 Oct 2025 16:19:06 GMT
Subject: [jfx25u] Integrated: 8368166: Media query should accept multiple rules
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 10:28:00 GMT, Michael Strau?  wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a176dad2](https://github.com/openjdk/jfx/commit/a176dad2a2da9f0fac25c6b0ff2028b49f59a526) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strau? on 3 Oct 2025 and was reviewed by Andy Goryachev and Ambarish Rapte.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cb8fe9ed
Author:    Michael Strau? 
URL:       https://git.openjdk.org/jfx25u/commit/cb8fe9ed03397bfad5204b6bd9ee2087cd0704d7
Stats:     106 lines in 2 files changed: 79 ins; 19 del; 8 mod

8368166: Media query should accept multiple rules

Backport-of: a176dad2a2da9f0fac25c6b0ff2028b49f59a526

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

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

From thiago.sayao at gmail.com  Fri Oct  3 17:08:51 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 3 Oct 2025 14:08:51 -0300
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: 
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
 <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
 
Message-ID: 

Ooops, forget it. It falls back to software rendering, because the correct
parameter is GLX_NONE not None.



Em sex., 3 de out. de 2025 ?s 12:55, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> On X11GLFactory.c
>
> Around line 92 on setGLXAttrs, add:
>
> glxAttrs[index++] = GLX_CONFIG_CAVEAT;
> glxAttrs[index++] = None;
>
> It does seem to fix the problem.
>
>
> Em sex., 3 de out. de 2025 ?s 00:03, Michael Zucchi 
> escreveu:
>
>> On 3/10/25 03:34, Thiago Milczarek Say?o wrote:
>>
>> I confess I did not understand much about the problem.
>>
>> Is it about variable refresh rates?
>> If I think a message _VARIABLE_REFRESH is received on the Notify event.
>>
>> No, I'm pretty sure I would have mentioned that if it was!
>>
>> Or
>> https://docs.gtk.org/gdk3/class.FrameClock.html
>>
>> I came across that but as far as I can tell that's only for gtk widget's
>> rendering pipeline which isn't relevant, apart from maybe an example of how
>> to do it.
>>
>> I also did an EGL version in place of GLX:
>> https://github.com/openjdk/jfx/pull/1381
>>
>> Fair enough.  I may see if that makes any difference another time,
>> although the eglSwapBuffers() man page isn't really any different to the
>> glX one and afaict from a quick look at the mesa source it all ends up at
>> the same place internally.
>>
>> -- Thiago
>>
>>
>> It's a couple of things.
>>
>> I experience the bug mentioned in the title with a trivial test programme
>> (first email to list) and default settings - I get uncapped pulses/second
>> on multiple AMD systems - ~600/s on a laptop and ~2000/s on a desktop.
>> It's just burning cpu and battery for no good reason.  It's probably due to
>> a bug in mesa or amdgpu exposed due to the way javafx swaps around gl
>> contexts.
>>
>> It's about incorrect assumptions about the behaviour of the GLX api -
>> i.e. that glXSwapBuffers() on a double-buffered window will block waiting
>> for vsync in the same way Direct3D's Present() with the provided flags
>> does.  This is not correct[1], and even when GLX does throttle it wont
>> necessarily throttle where expected so that 'vsyncHint()' has any meaning.
>> The man page offers the correction: glFinish(), but that doesn't work if
>> executed per-window.
>>
>> It's also about just poor timing code / api in general.
>> gdk_threads_add_timeout_full's man page:
>>
>> Note that timeout functions may be delayed, due to the processing of
>> other event sources. Thus they should not be relied on for precise timing.
>> After each call to the timeout function, the time of the next timeout is
>> recalculated based on the current time and the given interval (it does not
>> try to ?catch up? time lost in delays).
>>
>> There is some messy code to try to account for that looseness when vsync
>> (the default) is requested (vsyncHint() and associated), but not
>> otherwise.  But even without that the api has such limited precision it
>> just doesn't work very well.  i.e. setting prism.vsync=false
>> javafx.animation.pulse=60 wont give you even a jittery 60/s pulse rate - it
>> will be a jittery higher one.  It seems very low hanging fruit to fix.
>>
>>  Z
>>
>> [1]
>> https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXSwapBuffers.xml
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kizune at openjdk.org  Fri Oct  3 20:54:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 3 Oct 2025 20:54:14 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component
Message-ID: 

Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

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

Commit messages:
 - Fixing wrong copyright year
 - Fixing the assignment;
 - Fixed typo
 - 8368972: Create implementation of menu bar accessibility component

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

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

From angorya at openjdk.org  Fri Oct  3 21:20:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 3 Oct 2025 21:20:04 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 20:49:21 GMT, Alexander Zuev  wrote:

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

Reviewers: @andy-goryachev-oracle @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3367237661

From kcr at openjdk.org  Fri Oct  3 21:49:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 21:49:39 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
Message-ID: 

Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.

As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).

Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

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

Commit messages:
 - 8369140: GHA: Update macOS / x64 build to use macos-15-intel runner

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

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

From kcr at openjdk.org  Fri Oct  3 21:49:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 21:49:40 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 21:42:16 GMT, Kevin Rushforth  wrote:

> Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.
> 
> As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).
> 
> Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

I see that the GHA build on Linux failed with a known intermittent test failure that is unrelated to this change (which only touches macOS / x64 GHA builds).

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

PR Comment: https://git.openjdk.org/jfx/pull/1928#issuecomment-3367303833

From kcr at openjdk.org  Fri Oct  3 22:14:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 22:14:06 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 21:42:16 GMT, Kevin Rushforth  wrote:

> Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.
> 
> As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).
> 
> Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

As noted in the above blog, this solution will last us until the fall of 2027. Beyond that there will be no solution for testing builds on macOS / x64. Once the `mac-15-intel` runner is retired, we will need to remove the macOS / x64 platform from our GHA test matrix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1928#issuecomment-3367365754

From kcr at openjdk.org  Fri Oct  3 22:56:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Oct 2025 22:56:01 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
In-Reply-To: 
References: 
 
Message-ID: <8x--Tlb3pc1YvAjbMnx66fyGkYI8otEleczpiBGHJcw=.432d64ab-d8ad-4177-80b4-f411b40cafb7@github.com>

On Fri, 3 Oct 2025 21:46:05 GMT, Kevin Rushforth  wrote:

> I see that the GHA build on Linux failed with a known intermittent test failure that is unrelated to this change (which only touches macOS / x64 GHA builds).

I reran the failing Linux job and it passed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1928#issuecomment-3367462487

From angorya at openjdk.org  Fri Oct  3 23:02:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 3 Oct 2025 23:02:12 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component
In-Reply-To: 
References: 
Message-ID: <5ptq3X5G3GS1VFnFeJZxm7gaybcQrsYKZrbn8VKWuUU=.ec86c1f6-0ffc-4898-9974-f2f3dfeb210f@github.com>

On Fri, 3 Oct 2025 20:49:21 GMT, Alexander Zuev  wrote:

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

I see no difference in VoiceOver announcements between master and this PR - is it expected?

One thing I noticed is that when the pulldown menu is shown, and I hit LEFT or RIGHT arrow keys, the VoiceOver does not announce the current menu (either master or this PR, so it might be a pre-existing issue).  It does announce the name of the current menu occasionally, but I can't quite determine when.

Screenshot 2025-10-03 at 15 52 36

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3367470599

From jhendrikx at openjdk.org  Sat Oct  4 04:26:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 4 Oct 2025 04:26:23 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 3 Oct 2025 14:46:06 GMT, Marius Hanl  wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 368:
>> 
>>> 366:         JMemoryBuddy.assertCollectable(ref);
>>> 367:     }
>>> 368: 
>> 
>> Is there another test that verifies that cells are garbage collectable?  For example, in the case where a table / list / tree table becomes smaller visually, I think that it should then perhaps discard some cells that then should be collectable?
>
> I think there are some when switching the `TableRow`, as this should remove all old rows and gc them at one point.
> 
> Other than that, I think there is no case where we gc cells. When we change the viewport width/height, all rows (cells if a `fixedCellSize` is set) will be piled / cached, but not destroyed.

Alright, as long as there are still some GC checks I think this would be fine.  Not sure if I agree with keeping cells/rows around that exceed the amount that are currently displayed, but that's how it already works (my own virtualized controls will only reference the cells displayed, but with non-fixed size cells/rows this may not be optimal).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2403736449

From jhendrikx at openjdk.org  Sat Oct  4 04:31:27 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 4 Oct 2025 04:31:27 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 19:47:41 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl 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' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
>  - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

Marked as reviewed by jhendrikx (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3301553048

From jhendrikx at openjdk.org  Sat Oct  4 04:31:27 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 4 Oct 2025 04:31:27 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>

On Fri, 3 Oct 2025 14:49:10 GMT, Marius Hanl  wrote:

> > I think the changes look good. I'm a bit confused in the performance table with what is meant with the `50 ms -> 0 ms` in the "after" cases though?
> 
> Every `refresh()` will trigger 2 layouts for some reason, where the second one does nothing as nothing is dirty, so basically a noop. I can have a look into that (maybe as a follow up?) but I remember that this happens sometimes in general for the `VirtualFlow` and we should check that generally at one point.

No need to address that in this PR,  I was just confused what the numbers meant (shouldn't the `before` column than not also have `X ms -> 0 ms`?).  So it seems like quite a good performance improvement.

As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/  How many cells were visible?  1000 or 100x1000?  If the latter, than 30-40 ms seems okayish.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3367883240

From tsayao at openjdk.org  Sat Oct  4 12:48:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 4 Oct 2025 12:48:02 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
In-Reply-To: 
References: 
Message-ID: <52N2ygLxHpNMXADFU-fMsmz_JlXWTvIv-2FYwCllgyw=.ad414119-0066-443d-9d92-86465793923f@github.com>

On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox  wrote:

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

Tested on:

- Debian 12 / KDE (sunpinyin and pt_br)
- Ubuntu 24.04 / GNOME with fcitx (pinyin, mozc, pt_br) and ibus (pinyin, pt_br)
- Linux Mint (pt_br no IME)

all good.

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

PR Comment: https://git.openjdk.org/jfx/pull/1924#issuecomment-3368194854

From tsayao at openjdk.org  Sat Oct  4 13:43:59 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 4 Oct 2025 13:43:59 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate
Message-ID: 

As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.

I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.

It also selects the correct visual for transparency which needs to be depth = 32 for X11.

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

Commit messages:
 - [Linux] Uncontrolled framerate

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

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

From kcr at openjdk.org  Sat Oct  4 14:14:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 4 Oct 2025 14:14:02 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate
In-Reply-To: 
References: 
Message-ID: 

On Sat, 4 Oct 2025 13:38:47 GMT, Thiago Milczarek Sayao  wrote:

> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
> 
> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
> 
> It also selects the correct visual for transparency which needs to be depth = 32 for X11.

Reviewers: @kevinrushforth @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3368287755

From kcr at openjdk.org  Sat Oct  4 14:14:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 4 Oct 2025 14:14:01 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
In-Reply-To: <52N2ygLxHpNMXADFU-fMsmz_JlXWTvIv-2FYwCllgyw=.ad414119-0066-443d-9d92-86465793923f@github.com>
References: 
 <52N2ygLxHpNMXADFU-fMsmz_JlXWTvIv-2FYwCllgyw=.ad414119-0066-443d-9d92-86465793923f@github.com>
Message-ID: <9jRzmzNtDm1r88i9b7eJm2NF6HDP-24oJ8zRV9sy_R0=.d4b582d8-041f-48b3-9b84-8528d06bba36@github.com>

On Sat, 4 Oct 2025 12:45:34 GMT, Thiago Milczarek Sayao  wrote:

>> 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.
>
> Tested on:
> 
> - Debian 12 / KDE (sunpinyin and pt_br)
> - Ubuntu 24.04 / GNOME with fcitx (pinyin, mozc, pt_br) and ibus (pinyin, pt_br)
> - Linux Mint (pt_br no IME)
> 
> all good.

@tsayao Would you be willing to review (approve) the PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1924#issuecomment-3368287565

From tsayao at openjdk.org  Sat Oct  4 14:43:58 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 4 Oct 2025 14:43:58 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate
In-Reply-To: 
References: 
Message-ID: 

On Sat, 4 Oct 2025 13:38:47 GMT, Thiago Milczarek Sayao  wrote:

> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
> 
> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
> 
> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
> 
> It also selects the correct visual for transparency which needs to be depth = 32 for X11.

I'm not sure of the solution, but it's a starting point.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3368309541

From kcr at openjdk.org  Sat Oct  4 15:04:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 4 Oct 2025 15:04:00 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
In-Reply-To: <9jRzmzNtDm1r88i9b7eJm2NF6HDP-24oJ8zRV9sy_R0=.d4b582d8-041f-48b3-9b84-8528d06bba36@github.com>
References: 
 <52N2ygLxHpNMXADFU-fMsmz_JlXWTvIv-2FYwCllgyw=.ad414119-0066-443d-9d92-86465793923f@github.com>
 <9jRzmzNtDm1r88i9b7eJm2NF6HDP-24oJ8zRV9sy_R0=.d4b582d8-041f-48b3-9b84-8528d06bba36@github.com>
Message-ID: <3La7KliFhmGUWvaNlL26YI6G3-Dj8_aw2Ct_98RG4vA=.93866665-6fab-4b89-80f8-0a90535a157a@github.com>

On Sat, 4 Oct 2025 14:10:52 GMT, Kevin Rushforth  wrote:

> /approve

No I meant as a GitHub review: Click on the "Files changed" tab at the top to review the PR, click on "Review changes", select "Approve", and enter an optional comment.

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

PR Comment: https://git.openjdk.org/jfx/pull/1924#issuecomment-3368321487

From tsayao at openjdk.org  Sat Oct  4 15:11:00 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 4 Oct 2025 15:11:00 GMT
Subject: RFR: 8367045: [Linux] Dead keys not working
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox  wrote:

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

Looks good. Thanks @beldenfox.

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

Marked as reviewed by tsayao (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1924#pullrequestreview-3301934276

From tsayao at openjdk.org  Sat Oct  4 15:19:32 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 4 Oct 2025 15:19:32 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
Message-ID: 

> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
> 
> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
> 
> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
> 
> It also selects the correct visual for transparency which needs to be depth = 32 for X11.

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

  Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1929/files
  - new: https://git.openjdk.org/jfx/pull/1929/files/0d006dd3..a27a99eb

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

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

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

From mfox at openjdk.org  Sat Oct  4 16:42:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 4 Oct 2025 16:42:58 GMT
Subject: Integrated: 8367045: [Linux] Dead keys not working
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Sep 2025 18:19:03 GMT, Martin Fox  wrote:

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

This pull request has now been integrated.

Changeset: d5e817d6
Author:    Martin Fox 
URL:       https://git.openjdk.org/jfx/commit/d5e817d6e4f28bb1e14292f17f7fe95f5d001487
Stats:     13 lines in 2 files changed: 12 ins; 0 del; 1 mod

8367045: [Linux] Dead keys not working

Reviewed-by: lkostyra, tsayao

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

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

From nlisker at openjdk.org  Sun Oct  5 01:09:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 5 Oct 2025 01:09:01 GMT
Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 2 Oct 2025 16:01:55 GMT, Kevin Rushforth  wrote:

> Since you didn't make any changes to the test source code, I presume that JUnit 6 is compatible with 5 (leaving aside the removed deprecations, which don't affect us), unlike the transition from 4 to 5 (version 5 was effectively an entirely new API). I'll take a look at the release notes, but can you summarize the changes you are aware of?

See https://github.com/junit-team/junit-framework/wiki/Upgrading-to-JUnit-6.0.

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

PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3368648359

From mhanl at openjdk.org  Sun Oct  5 17:14:24 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 5 Oct 2025 17:14:24 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
References: 
 
 
 
 <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
Message-ID: 

On Sat, 4 Oct 2025 04:28:19 GMT, John Hendrikx  wrote:

> As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/ How many cells were visible? 1000 or 100x1000? If the latter, than 30-40 ms seems okayish.

I agree. One problem here is, that all cells will be updated (via `updateItem`) of a `TableRow`, even if not visible. 

I counted all `updateItem` calls, results below.

Code from Benchmark above:
- `TableRow` `updateItem`: 78
- `TableCell` `updateItem`: 7800

39 rows are displayed, and they are updated twice (first with `-1` to reset, then with the actual index). And all rows have 100 cells.

A `TableCell` `updateItem` without any code (no `setText`, no `setGraphic`) is indeed faster, around 10-20ms.
Looking into the code, there are some unnecessary `requestLayout` calls as well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3369192707

From mhanl at openjdk.org  Sun Oct  5 20:10:02 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 5 Oct 2025 20:10:02 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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).
> 
> ----
> 
> Benchmarks
> -
> 
> Setup:
> - `TableView`
> - `100 TableColumns`
> - `1000 Items`
> 
> Calling `refresh()` with a `Button` press.
> 
> | WHAT | BEFORE | AFTER |
> | - | - | - |
> | Init | 0ms |0 ms |
> | Init | 0ms | 0 ms |
> | Init | 251 ms | 246 ms |
> | Init | 47 ms | 50 ms |
> | Init | 24 ms | 5 ms |
> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
> 
> 
> 
> 

> Benchmark code
> 
> 
> import javafx.application.Application;
> import javafx.beans.property.SimpleStringProperty;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.control.IndexedCell;
> import javafx.scene.control.TableColumn;
> import javafx.scene.control.TableRow;
> import javafx.scene.control.TableView;
> import javafx.scene.control.skin.TableViewSkin;
> import javafx.scene.control.skin.VirtualFlow;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.HBox;
> import javafx.stage.Stage;
> 
> public class FXBug {
> 
>     public static void main(String[] args) {
>         Application.launch(FxApp.class, args);
>     }
> 
>     public static class FxApp extends Application {
> 
>         @Override
>         public void start(Stage primaryStage) {
>             TableV...

Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:

 - remove newline from imports
 - assert row creation count as well

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1830/files
  - new: https://git.openjdk.org/jfx/pull/1830/files/940f7cbd..1376cb3b

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

  Stats: 211 lines in 4 files changed: 97 ins; 77 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1830.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1830/head:pull/1830

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

From hmeda at openjdk.org  Mon Oct  6 03:55:05 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 6 Oct 2025 03:55:05 GMT
Subject: Integrated: 8368691: Update libxml2 to 2.14.6
In-Reply-To: 
References: 
Message-ID: <9LE6kg21A5F0NmqIdrVLZuxdk3z-Xgi5JT0BJKBejck=.6288234d-56dc-4cd3-b3ef-75c17f692cb7@github.com>

On Thu, 25 Sep 2025 12:37:48 GMT, Hima Bindu Meda  wrote:

> Updated libxml2 to v2.14.6. Verified build on all platforms. No issue seen.

This pull request has now been integrated.

Changeset: 6ab42f99
Author:    Hima Bindu Meda 
URL:       https://git.openjdk.org/jfx/commit/6ab42f99914c1d1e504432957aba992e2b98e377
Stats:     123 lines in 16 files changed: 74 ins; 11 del; 38 mod

8368691: Update libxml2 to 2.14.6

Reviewed-by: kcr, sykora

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

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

From arapte at openjdk.org  Mon Oct  6 11:08:04 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 6 Oct 2025 11:08:04 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 26 Sep 2025 10:29:44 GMT, Ambarish Rapte  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

@tiainen please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1918#issuecomment-3371062118

From mariushanl at web.de  Mon Oct  6 11:29:32 2025
From: mariushanl at web.de (Marius Hanl)
Date: Mon, 6 Oct 2025 11:29:32 +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: 

Vote: Yes

-- Marius



> Gesendet: Montag, 29. September 2025 um 21:29
> Von: "Kevin Rushforth" 
> An: openjfx-dev , "Ziad El Midaoui" 
> Betreff: 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
> 
> 

From nlisker at openjdk.org  Mon Oct  6 12:05:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 6 Oct 2025 12:05:03 GMT
Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.0
In-Reply-To: 
References: 
Message-ID: 

On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl  wrote:

> JUnit 6.0.0 is out and we can consider updating to it.
> 
> Release Notes: https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.0
> 
> Notes:
> - Java 17 is the baseline (so not a problem for us, since we have a higher baseline)
> - Deprecation were removed (not a problem, as we don't rely on any)
> - JUnit Vintage Engine is deprecated (not a problem, as we dropped support for it some months ago)
> 
> JUnit 6 now uses a single version number for all dependencies, that is platform, jupiter and vintage (which we do not use anymore). That makes updating it easier.
> 
> It also uses `JSpecify`, which is an annotation library for `@NonNull` and `@Nullable`. All version numbers for JUnit now use a single variable.

> I would suggest we postpone the migration to junit6 until after Eclipse provides support for it (screenshot taken with Eclipse Version: 2025-06 (4.36) Build id: I20250528-1830):
> 
> Screenshot 2025-10-02 at 10 46 25

The JUnit 5 runner works with JUnit 6. I don't know if they'll add another item to that list or just rename it to "JUnit 5+" for example.

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

PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3371298053

From ambarish.rapte at oracle.com  Mon Oct  6 12:12:17 2025
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 6 Oct 2025 12:12:17 +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: 

Vote: Yes
~Ambarish

From: openjfx-dev  on behalf of Kevin Rushforth 
Date: Tuesday, 30 September 2025 at 00:59
To: openjfx-dev , Ziad El Midaoui 
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



Confidential - Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin.rushforth at oracle.com  Mon Oct  6 12:38:45 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 6 Oct 2025 05:38:45 -0700
Subject: WebView wv = new WebView(); throws an exception
In-Reply-To: 
References: 
Message-ID: <78649008-831e-47b9-a4f7-267fac48dd6b@oracle.com>

[re-routing to openjfx-dev]

Technical questions should be discussed on openjfx-dev.

There isn't enough information to be sure, but you might double-check 
whether you are creating the WebView on the JavaFX application thread. 
If not, you are running into a known bug, JDK-8087718 [1].

-- Kevin

[1] https://bugs.openjdk.org/browse/JDK-8087718

On 10/4/2025 9:10 AM, Davide Perini wrote:
> Hi there,
>
> I noticed recently that this code
> WebView wv = new WebView();
> throws an exception that creates no real problem but it is a bit annoyng.
>
> The exception is thrown here:
> class PropertyHelper {
> ? ? static boolean getBooleanProperty(String var0) {
> ? ? ? ? try {
> ? ? ? ? ? ? String var1 = System.getProperty(var0);
> ? ? ? ? ? ? return "true".equals(var1.toLowerCase());
> ? ? ? ? } catch (Exception var2) {
> ? ? ? ? ? ? return false;
> ? ? ? ? }
> ? ? }
> }
>
> If I manually set
> System.setProperty("javafx.sg.warn", "true");
>
> this exception is not thrown.
>
> But why?
>


From kcr at openjdk.org  Mon Oct  6 12:44:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Oct 2025 12:44:58 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 21:42:16 GMT, Kevin Rushforth  wrote:

> Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.
> 
> As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).
> 
> Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

Reviewer: @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1928#issuecomment-3371444447

From kcr at openjdk.org  Mon Oct  6 13:19:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Oct 2025 13:19:10 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao  wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

@arapte If you could also take a look that would be helpful.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3371595483

From hmeda at openjdk.org  Mon Oct  6 13:26:29 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 6 Oct 2025 13:26:29 GMT
Subject: [jfx25u] RFR: 8368691: Update libxml2 to 2.14.6
Message-ID: <3Md0eQMgy85vb4dheyp0eS3m8gv_46mBLUd7XoTe1D4=.42451964-c2ae-475c-b443-b8d7e6e77629@github.com>

Clean Backport. Updated libxml2 to v2.14.6. Verified build and sanity on all platforms.

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

Commit messages:
 - Backport 6ab42f99914c1d1e504432957aba992e2b98e377

Changes: https://git.openjdk.org/jfx25u/pull/22/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=22&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/jfx25u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/22/head:pull/22

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

From arapte at openjdk.org  Mon Oct  6 16:42:39 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 6 Oct 2025 16:42:39 GMT
Subject: RFR: 8369140: GHA: Update macOS / x64 build to use macos-15-intel
 runner
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 21:42:16 GMT, Kevin Rushforth  wrote:

> Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.
> 
> As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).
> 
> Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1928#pullrequestreview-3305930941

From arapte at openjdk.org  Mon Oct  6 16:49:37 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 6 Oct 2025 16:49:37 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 20:49:21 GMT, Alexander Zuev  wrote:

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 65:

> 63:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"MENU_ITEM"];
> 64:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"RADIO_MENU_ITEM"];
> 65:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"CHECK_MENU_ITEM"];

Is the removal of CHECK_MENU_ITEM intentional ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2407410274

From hmeda at openjdk.org  Mon Oct  6 18:05:19 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 6 Oct 2025 18:05:19 GMT
Subject: [jfx25u] Integrated: 8368691: Update libxml2 to 2.14.6
In-Reply-To: <3Md0eQMgy85vb4dheyp0eS3m8gv_46mBLUd7XoTe1D4=.42451964-c2ae-475c-b443-b8d7e6e77629@github.com>
References: <3Md0eQMgy85vb4dheyp0eS3m8gv_46mBLUd7XoTe1D4=.42451964-c2ae-475c-b443-b8d7e6e77629@github.com>
Message-ID: 

On Mon, 6 Oct 2025 13:21:09 GMT, Hima Bindu Meda  wrote:

> Clean Backport. Updated libxml2 to v2.14.6. Verified build and sanity on all platforms.

This pull request has now been integrated.

Changeset: d375bed1
Author:    Hima Bindu Meda 
URL:       https://git.openjdk.org/jfx25u/commit/d375bed12f4e5cb41ce92c875d18347c7450fe86
Stats:     123 lines in 16 files changed: 74 ins; 11 del; 38 mod

8368691: Update libxml2 to 2.14.6

Backport-of: 6ab42f99914c1d1e504432957aba992e2b98e377

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

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

From kizune at openjdk.org  Mon Oct  6 18:31:30 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 6 Oct 2025 18:31:30 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
Message-ID: 

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

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

  Restore CHECK_MENU_ITEM binding

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1927/files
  - new: https://git.openjdk.org/jfx/pull/1927/files/0d350c07..fe7d12bc

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

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

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

From kizune at openjdk.org  Mon Oct  6 18:31:33 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 6 Oct 2025 18:31:33 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
 
Message-ID: <83y9IIiInuGArwkw-SlmlrxTBkVChbeMtbiVLLHbsKg=.7eccb380-34cd-45d3-b47a-c2d48f6dc94b@github.com>

On Mon, 6 Oct 2025 16:47:26 GMT, Ambarish Rapte  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore CHECK_MENU_ITEM binding
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 65:
> 
>> 63:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"MENU_ITEM"];
>> 64:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"RADIO_MENU_ITEM"];
>> 65:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"CHECK_MENU_ITEM"];
> 
> Is the removal of CHECK_MENU_ITEM intentional ?

No, that was an accident.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2407840731

From angorya at openjdk.org  Mon Oct  6 18:31:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Oct 2025 18:31:33 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: <83y9IIiInuGArwkw-SlmlrxTBkVChbeMtbiVLLHbsKg=.7eccb380-34cd-45d3-b47a-c2d48f6dc94b@github.com>
References: 
 
 <83y9IIiInuGArwkw-SlmlrxTBkVChbeMtbiVLLHbsKg=.7eccb380-34cd-45d3-b47a-c2d48f6dc94b@github.com>
Message-ID: 

On Mon, 6 Oct 2025 18:23:45 GMT, Alexander Zuev  wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 65:
>> 
>>> 63:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"MENU_ITEM"];
>>> 64:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"RADIO_MENU_ITEM"];
>>> 65:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"CHECK_MENU_ITEM"];
>> 
>> Is the removal of CHECK_MENU_ITEM intentional ?
>
> No, that was an accident.

... and I totally missed that!
Question: how come none of the tests failed?  Do we have test coverage in this area?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2407849842

From kizune at openjdk.org  Mon Oct  6 18:31:34 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 6 Oct 2025 18:31:34 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
 
 <83y9IIiInuGArwkw-SlmlrxTBkVChbeMtbiVLLHbsKg=.7eccb380-34cd-45d3-b47a-c2d48f6dc94b@github.com>
 
Message-ID: 

On Mon, 6 Oct 2025 18:25:30 GMT, Andy Goryachev  wrote:

>> No, that was an accident.
>
> ... and I totally missed that!
> Question: how come none of the tests failed?  Do we have test coverage in this area?

I do not think so - and i do not think the non-manual test would be possible and even with the manual test it will pass because removal of binding just means that old code will be used and the old code still works - until Apple pulls the plug on old API.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2407863516

From kizune at openjdk.org  Mon Oct  6 18:35:31 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 6 Oct 2025 18:35:31 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component
In-Reply-To: <5ptq3X5G3GS1VFnFeJZxm7gaybcQrsYKZrbn8VKWuUU=.ec86c1f6-0ffc-4898-9974-f2f3dfeb210f@github.com>
References: 
 <5ptq3X5G3GS1VFnFeJZxm7gaybcQrsYKZrbn8VKWuUU=.ec86c1f6-0ffc-4898-9974-f2f3dfeb210f@github.com>
Message-ID: 

On Fri, 3 Oct 2025 22:59:05 GMT, Andy Goryachev  wrote:

> I see no difference in VoiceOver announcements between master and this PR - is it expected?
Yes.
 
> One thing I noticed is that when the pulldown menu is shown, and I hit LEFT or RIGHT arrow keys, the VoiceOver does not announce the current menu (either master or this PR, so it might be a pre-existing issue). It does announce the name of the current menu occasionally, but I can't quite determine when.

When the pull down menu is shown the accessibility focus is on the popup itself (unless you select a menu item in it) and we still did not find any way to tell VoiceOver that the popup has some name - we added all the possible API methods - label, title, titleElement, value, name - VO just ignores all of them so unfortunately there's nothing we can do on our side. This API is not wired for the per-window menu.

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3373288447

From angorya at openjdk.org  Mon Oct  6 18:39:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Oct 2025 18:39:13 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 6 Oct 2025 18:31:30 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore CHECK_MENU_ITEM binding

thanks for the explanations!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1927#pullrequestreview-3306546875

From kcr at openjdk.org  Mon Oct  6 22:20:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Oct 2025 22:20:02 GMT
Subject: Integrated: 8369140: GHA: Update macOS / x64 build to use
 macos-15-intel runner
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 21:42:16 GMT, Kevin Rushforth  wrote:

> Update our GitHub Actions scripts to use the `macos-15-intel` runner for macOS / x64 test builds.
> 
> As noted in [this blog post](https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/), GitHub will retire their `macos-13` runner later this fall. We use the macos-13 runner to build on macOS / x64 (the macos-14 runner builds on macOS / aarch64).
> 
> Note that the GitHub macos-15 runners have Xcode 16.0 as the minimum version of Xcode rather than the Xcode 15.4 that we use in production. This is fine, and has the added benefit of early detection if we introduce any Xcode 16 bugs. We will continue to run macOS / aarch64 builds using the macos-14 runner with Xcode 15.4.

This pull request has now been integrated.

Changeset: e8820e24
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/e8820e2482bbc00765975854e738fdc214a46ea4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8369140: GHA: Update macOS / x64 build to use macos-15-intel runner

Reviewed-by: arapte

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

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

From kcr at openjdk.org  Tue Oct  7 00:30:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Oct 2025 00:30:12 GMT
Subject: [jfx25u] RFR: 8369140: GHA: Update macOS / x64 build to use
 macos-15-intel runner
Message-ID: 

Clean backport of GHA fix to jfx25u.

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

Commit messages:
 - Backport e8820e2482bbc00765975854e738fdc214a46ea4

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

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

From ajit.ghaisas at oracle.com  Tue Oct  7 05:24:00 2025
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Tue, 7 Oct 2025 05:24:00 +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: <964BF6A2-4759-4769-AD53-F49BB433A724@oracle.com>

Vote: Yes

Regards,
Ajit

> On 30 Sep 2025, at 12:59?AM, 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 notzed at gmail.com  Tue Oct  7 05:47:05 2025
From: notzed at gmail.com (Michael Zucchi)
Date: Tue, 7 Oct 2025 16:17:05 +1030
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: 
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
 <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
 
Message-ID: 

On 4/10/25 01:20, Thiago Milczarek Say?o wrote:
> Just out of curiosity, I compiled the EGL version. Here:
> https://github.com/tsayao/jfx/releases/tag/test-egl
>
> It does seem to have a difference in frame rate.
>

That's a lot better, it's basically the same as if I remove the 
makeCurrent() from ES2Pipeline.present and I presume how it behaves on 
other systems.? I still think it's throttling in the wrong place and the 
GlassTimer is terrible,? but at least it's throttling.? I'll probably 
try 25 with the latest mesa and if i still see it file a bug with them.

Over the last few days I did a lot of analysis with a more complex 
application - one that calculates an image sequence via OpenCL and 
displays it in JavaFX.? The OpenCL takes from about 3 to 15ms to 
complete depending on the scene.? I've attached some inter-pulse timing 
plots which are a bit more interesting than the previous ones.

There's JavaFX 25, my patches (Z), and the with your EGL build (I also 
tested with the makeCurrent() change since it's a single window, and it 
matches the EGL one).

 From left to right, top to bottom:

 1. Transition with no frame-rate, asynchronous rendering that drops
    work if a new request comes in while it's busy.
 2. Transition with 60f/s desired frame rate, asynchronous rendering as 1.
 3. Transition with no frame-rate, synchronous rendering on the
    animation thread.
 4. Transition with 60/s desired frame rate, synchronous rendering as 3.


Setting a desired frame rate on the Transition results in considerable 
microstutter even with the egl version.? Not setting a desired frame 
rate - visually it's ok but there is still more frame pacing variation 
than calling glFinish() after all scenes have been drawn and with a more 
accurate timer.

I want to try to do some latency testing if I can work out a reasonable 
way to do it.

For what it's worth i've also attached current patch-in-progress that 
includes a more accurate if rather simple timer.

Regards,
 ?!Z


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mand_jfx_25.png
Type: image/png
Size: 14638 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mand_jfx_z.png
Type: image/png
Size: 13599 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mand_jfx_egl.png
Type: image/png
Size: 14651 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: javafx-vsync-timer.diff
Type: text/x-patch
Size: 14572 bytes
Desc: not available
URL: 

From michaelstrau2 at gmail.com  Tue Oct  7 08:47:21 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 7 Oct 2025 10:47:21 +0200
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
Message-ID: 

Markdown comments are not _better_ than HTML comments, they are just
different. In particular, I question the unsubstantiated claim that
markdown comments are more readable; I've never once struggled with
reading HTML comments, especially if you use the recent additions like
{@snippet}.

I might use markdown comments myself if I were to start a greenfield
project. But in a mature project, consistency is more important than
(at best) tiny ergonomic improvements. In fact, consistency is one of
the most important factors contributing to ergonomy. You point out
that you wouldn't want to invite wholesale refactoring, but to be
fair, I'd rather have a wholesale refactor to use markdown comments
everywhere than be forever annoyed to see two wildly different comment
styles next to each other.

I've looked at recent CSRs and API additions in the JDK, and haven't
found a single one using markdown comments. Why the rush to be the
first project to use them?

In any case, if we end up allowing markdown comments, I would strongly
suggest to only allow a single comment style per file. Mixing both
styles in a single file is an unmitigated readability disaster.



On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
 wrote:
>
> Now that JavaFX requires JDK 24 to build, we can use features from JDK
> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
> delivered in JDK 23.
>
> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
> proposed changes that do just that.
>
> As was pointed out in a review comment on PR 1873 [3], we should make a
> deliberate decision to start using them and have some guidelines around
> doing so.
>
> To that end, I would propose that developers can start using markdown
> javadoc comments in new APIs and in APIs that are modified such that
> markdown comments would be helpful.
>
> This is not an invitation to do wholesale changing of existing javadoc
> comments to markdown-style comments for docs that otherwise aren't being
> modified.
>
> Comments are welcome.
>
> -- Kevin
>
> [0] https://openjdk.org/jeps/467
> [1] https://github.com/openjdk/jfx/pull/1873
> [2] https://github.com/openjdk/jfx/pull/1880
> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>

From jayathirth.d.v at oracle.com  Tue Oct  7 09:29:49 2025
From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy)
Date: Tue, 7 Oct 2025 09:29:49 +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: 

Vote : Yes.

Thanks,
Jay



Confidential ? Oracle Internal
From: openjfx-dev  on behalf of Kevin Rushforth 
Date: Tuesday, 30 September 2025 at 12:59?AM
To: openjfx-dev , Ziad El Midaoui 
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: 

From arapte at openjdk.org  Tue Oct  7 12:21:18 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 7 Oct 2025 12:21:18 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 6 Oct 2025 18:31:30 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore CHECK_MENU_ITEM binding

modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXMenuItemAccessibility.m line 46:

> 44:         }
> 45:     }
> 46:     return [super accessibilityTitle];

A couple recommendations for this method: 
1. Use `nil` instead of `NULL`
2. Store `[super accessibilityChildren]` locally


- (NSString * _Nullable)accessibilityLabel {
    NSString *accTitle = [super accessibilityTitle];
    if (accTitle != nil) {
        return accTitle;
    }

    NSArray *accChildren = [super accessibilityChildren];
    if (accChildren != nil && accChildren.count != 0) {
        id child0 = accChildren[0];
        if ([child0 respondsToSelector:@selector(accessibilityValue)]) {
            return [child0 accessibilityValue];
        }
    } else {
        return @"";
    }
    return nil;
}

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2410432983

From thiago.sayao at gmail.com  Tue Oct  7 12:22:34 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 7 Oct 2025 09:22:34 -0300
Subject: JDK-8210547[linux] frame pacing etc.
In-Reply-To: 
References: 
 
 <5386517c-5ae6-4028-be42-8185a1e2977d@oracle.com>
 
 
 <586c170a-1123-44fb-aa2f-d1cc35b28e6f@gmail.com>
 
 
Message-ID: 

Hi Michael,

could you take a look at?
https://github.com/openjdk/jfx/pull/1929

It's based on the assumption that glxSwapIntervalEXT (rather than
glxSwapIntervalSGI) works with glFinish() per drawable rather than per
application.
But I'm unsure of it.

-- Thiago


Em ter., 7 de out. de 2025 ?s 02:47, Michael Zucchi 
escreveu:

> On 4/10/25 01:20, Thiago Milczarek Say?o wrote:
>
> Just out of curiosity, I compiled the EGL version. Here:
> https://github.com/tsayao/jfx/releases/tag/test-egl
>
> It does seem to have a difference in frame rate.
>
>
> That's a lot better, it's basically the same as if I remove the
> makeCurrent() from ES2Pipeline.present and I presume how it behaves on
> other systems.  I still think it's throttling in the wrong place and the
> GlassTimer is terrible,  but at least it's throttling.  I'll probably try
> 25 with the latest mesa and if i still see it file a bug with them.
>
> Over the last few days I did a lot of analysis with a more complex
> application - one that calculates an image sequence via OpenCL and displays
> it in JavaFX.  The OpenCL takes from about 3 to 15ms to complete depending
> on the scene.  I've attached some inter-pulse timing plots which are a bit
> more interesting than the previous ones.
>
> There's JavaFX 25, my patches (Z), and the with your EGL build (I also
> tested with the makeCurrent() change since it's a single window, and it
> matches the EGL one).
>
> From left to right, top to bottom:
>
>    1. Transition with no frame-rate, asynchronous rendering that drops
>    work if a new request comes in while it's busy.
>    2. Transition with 60f/s desired frame rate, asynchronous rendering as
>    1.
>    3. Transition with no frame-rate, synchronous rendering on the
>    animation thread.
>    4. Transition with 60/s desired frame rate, synchronous rendering as 3.
>
>
> Setting a desired frame rate on the Transition results in considerable
> microstutter even with the egl version.  Not setting a desired frame rate -
> visually it's ok but there is still more frame pacing variation than
> calling glFinish() after all scenes have been drawn and with a more
> accurate timer.
>
> I want to try to do some latency testing if I can work out a reasonable
> way to do it.
>
> For what it's worth i've also attached current patch-in-progress that
> includes a more accurate if rather simple timer.
>
> Regards,
>  !Z
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Tue Oct  7 13:21:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Oct 2025 13:21:49 GMT
Subject: [jfx25u] RFR: 8369140: GHA: Update macOS / x64 build to use
 macos-15-intel runner
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 00:21:15 GMT, Kevin Rushforth  wrote:

> Clean backport of GHA fix to jfx25u.

@johanvos Can you approve this PR when you get a chance?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/23#issuecomment-3376863847

From arapte at openjdk.org  Tue Oct  7 13:30:07 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 7 Oct 2025 13:30:07 GMT
Subject: RFR: 8365577: Revert to OpenGL as the default JavaFX rendering
 pipeline for macOS
Message-ID: 

On macOS, the default rendering pipeline was temporarily set to Metal.
This change reverts it to es2, by simply reverting the commit fa2127cb3a3fc11238c5c8ce4cf0d15c4000f05c for [JDK-8365576](https://bugs.openjdk.org/browse/JDK-8365576): Temporarily make Metal the default JavaFX rendering pipeline for macOS

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

Commit messages:
 - Revert "8365576: Temporarily make Metal the default JavaFX rendering pipeline for macOS"

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

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

From john.hendrikx at gmail.com  Tue Oct  7 13:33:28 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 7 Oct 2025 15:33:28 +0200
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: 
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
Message-ID: <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>

I'm of the same mind.? I don't see a use case for markdown comments at
all in a
project as mature as JavaFX, and I'm unlikely to use them, even for new
files simply to be
more consistent with other existing files (and I may copy/paste docs
sometimes as well).

There are barely any code conventions in FX as it is (indent is?4
spaces, and general Java naming
conventions are the only ones that I think of that are consistent
through-out the project), but
a consistent Javadoc?style can also be?considered one currently... still.

--John

On 07/10/2025 10:47, Michael Strau? wrote:
> Markdown comments are not _better_ than HTML comments, they are just
> different. In particular, I question the unsubstantiated claim that
> markdown comments are more readable; I've never once struggled with
> reading HTML comments, especially if you use the recent additions like
> {@snippet}.
>
> I might use markdown comments myself if I were to start a greenfield
> project. But in a mature project, consistency is more important than
> (at best) tiny ergonomic improvements. In fact, consistency is one of
> the most important factors contributing to ergonomy. You point out
> that you wouldn't want to invite wholesale refactoring, but to be
> fair, I'd rather have a wholesale refactor to use markdown comments
> everywhere than be forever annoyed to see two wildly different comment
> styles next to each other.
>
> I've looked at recent CSRs and API additions in the JDK, and haven't
> found a single one using markdown comments. Why the rush to be the
> first project to use them?
>
> In any case, if we end up allowing markdown comments, I would strongly
> suggest to only allow a single comment style per file. Mixing both
> styles in a single file is an unmitigated readability disaster.
>
>
>
> On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
>  wrote:
>> Now that JavaFX requires JDK 24 to build, we can use features from JDK
>> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
>> delivered in JDK 23.
>>
>> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
>> proposed changes that do just that.
>>
>> As was pointed out in a review comment on PR 1873 [3], we should make a
>> deliberate decision to start using them and have some guidelines around
>> doing so.
>>
>> To that end, I would propose that developers can start using markdown
>> javadoc comments in new APIs and in APIs that are modified such that
>> markdown comments would be helpful.
>>
>> This is not an invitation to do wholesale changing of existing javadoc
>> comments to markdown-style comments for docs that otherwise aren't being
>> modified.
>>
>> Comments are welcome.
>>
>> -- Kevin
>>
>> [0] https://openjdk.org/jeps/467
>> [1] https://github.com/openjdk/jfx/pull/1873
>> [2] https://github.com/openjdk/jfx/pull/1880
>> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>>

From angorya at openjdk.org  Tue Oct  7 15:11:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Oct 2025 15:11:16 GMT
Subject: RFR: 8365577: Revert to OpenGL as the default JavaFX rendering
 pipeline for macOS
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 13:25:09 GMT, Ambarish Rapte  wrote:

> On macOS, the default rendering pipeline was temporarily set to Metal.
> This change reverts it to es2, by simply reverting the commit fa2127cb3a3fc11238c5c8ce4cf0d15c4000f05c for [JDK-8365576](https://bugs.openjdk.org/browse/JDK-8365576): Temporarily make Metal the default JavaFX rendering pipeline for macOS

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1930#pullrequestreview-3310600459

From kcr at openjdk.org  Tue Oct  7 15:59:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Oct 2025 15:59:48 GMT
Subject: RFR: 8365577: Revert to OpenGL as the default JavaFX rendering
 pipeline for macOS
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 13:25:09 GMT, Ambarish Rapte  wrote:

> On macOS, the default rendering pipeline was temporarily set to Metal.
> This change reverts it to es2, by simply reverting the commit fa2127cb3a3fc11238c5c8ce4cf0d15c4000f05c for [JDK-8365576](https://bugs.openjdk.org/browse/JDK-8365576): Temporarily make Metal the default JavaFX rendering pipeline for macOS

LGTM. This is a clean revert of the commit that temporarily changed the order.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1930#pullrequestreview-3310806503

From mstrauss at openjdk.org  Tue Oct  7 16:10:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 7 Oct 2025 16:10:36 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v9]
In-Reply-To: 
References: 
Message-ID: 

> 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 pull request now contains 13 commits:

 - resolve merge conflicts
 - Merge branch 'master' into feature/media-features-viewport-characteristics
   
   # Conflicts:
   #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
 - 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
 - ... and 3 more: https://git.openjdk.org/jfx/compare/e8820e24...3dabf1e0

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

Changes: https://git.openjdk.org/jfx/pull/1844/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=08
  Stats: 2501 lines in 38 files changed: 1981 ins; 198 del; 322 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 mfox at openjdk.org  Tue Oct  7 16:58:35 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 7 Oct 2025 16:58:35 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
References: 
 <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
Message-ID: 

On Tue, 30 Sep 2025 23:31:20 GMT, Pabulaner IV  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 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

I?ve been reviewing how the platform code interacts with the rest of the system. For others who want to take a look at this PR here?s a quick run-down of how the current master branch works.

When JavaFX is not embedded the toolkit builds a single NSMenu to use as the system menu. It installs that NSMenu as NSApp.mainMenu when the first top-level window is shown but before it becomes the key window. This happens inside the _setMenubar call in GlassWindow.m. That menu stays in place as NSApp.mainMenu for the lifetime of the JavaFX application. Subsequent calls to _setMenubar and the logic that sets NSApp.mainMenu inside windowDidBecomeKey: are basically no-ops since it?s always the same NSMenu and it has already been installed.

It might look like the system is setting a separate menubar for each window but it?s not. There?s only one, it stays in place, and the toolkit rebuilds its content as windows gain and lose focus. And it always contains at least one menu, namely the default application menu.

The system also calls _setMenubar to hand the system NSMenu to each PopupWindow when it?s first shown. There doesn?t seem to be any point to this; the NSMenu was already installed by the popup?s owner and MenuBarSkin ignores popups when updating the system menu bar.

When JavaFX is embedded none of the above happens.

This PR doesn?t seem to change any behavior in the non-embedded case. In the embedded case everything changes. JavaFX now builds a system-wide NSMenu and hands it off to each top-level window but it only gets installed when that window becomes key. The menu is un-installed when the window resigns key (and the previous mainMenu is restored). That?s all new behavior but it seems to be working reliably.

Also new with this PR: if a popup is displayed in an FXPanel the system will call _setMenubar to set the system menu. The platform code is handling this correctly (basically ignoring it) but the checks it?s making shouldn?t be necessary. It would be far better if createTKPopupStage stopped calling _setMenubar.

This PR is turning on some code further up in the system that can lead to some minor bugs. For example, if you add a MenuBar to an FXPanel?s scene and then turn on useSystemMenuBar the entire menubar will become inaccessible. This is similar to another bug that?s already present in the master branch; if you add a MenuBar to a PopupWindow and then turn on useSystemMenuBar the entire menubar will disappear. These issues are all contrived and it?s easy for developers to avoid them but it would be good to tighten up the code a bit. The bugs I?ve found so far are minor enough not to block this PR and could be addressed in a separate issue. This should be easy to clean up though I can?t personally provide further assistance until November.

(The primary problem is in MenuBarSkin.setSystemMenu. It crawls up the stage ownership chain to decide which MenuBar to use to populate the system menu bar. It should ignore windows that aren?t eligible for the system menu bar like embedded and popup stages. One possible solution is to call getMenubar on each stage to see if the toolkit initialized it with the system menu.)

Still no show-stoppers, just some unnecessary complications from the way PopupWindows keep trying to force the system menu onto the platform code and a few very minor bugs that no developer is likely to notice.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3377746473

From arapte at openjdk.org  Wed Oct  8 04:54:08 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 8 Oct 2025 04:54:08 GMT
Subject: RFR: 8368879: Intermittent crash on exit when disposing
 MTLRTTextureData
Message-ID: 

**Issue**:
Intermittent crash on exit in `MTLRTTextureData::dispose()` during toolkit shutdown
The crash is very rare and difficult to reproduce.

**Cause**:
While exiting an app, in `MTLContext.dispose()`, a Texture is released **after** the native peer MetalConext is disposed.
- MTLContext.dispose() method:

    @Override
    public void dispose() {
        nRelease(pContext);
        state = null;
        super.dispose();
    }


1. The `MTLContext.dispose()` method releases the native peer (`nRelease(pContext)`) before calling `super.dispose()` (i.e., `BaseShaderContext.dispose()`).
2. `BaseShaderContext.dispose()` calls `disposeLCDBuffer()` to dispose the LCD texture, which in turn invokes `MTLRTTextureData::dispose()`
=> As native MetalContext is already disposed, it causes a crash.

**Fix**:
Call `disposeLCDBuffer()` before `nRelease(pContext)`. so that the Texture is released **before** disposing the native peer MetalContext.
The scenario is very rare to reproduce, so no test is added.

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

Commit messages:
 - disposeLCDBuffer b4 nRelease(pContext)

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

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

From jdv at openjdk.org  Wed Oct  8 06:43:25 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 8 Oct 2025 06:43:25 GMT
Subject: RFR: 8365577: Revert to OpenGL as the default JavaFX rendering
 pipeline for macOS
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 13:25:09 GMT, Ambarish Rapte  wrote:

> On macOS, the default rendering pipeline was temporarily set to Metal.
> This change reverts it to es2, by simply reverting the commit fa2127cb3a3fc11238c5c8ce4cf0d15c4000f05c for [JDK-8365576](https://bugs.openjdk.org/browse/JDK-8365576): Temporarily make Metal the default JavaFX rendering pipeline for macOS

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1930#pullrequestreview-3313192172

From mariushanl at web.de  Wed Oct  8 08:00:34 2025
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 8 Oct 2025 08:00:34 +0000
Subject: Headless Tests in CI try to load shared libraries
Message-ID: 

Hi,

I recently tried to write headless tests by utilizing the new headless platform.
First of all, works great!

I noticed that the CI still tries to load shared libraries. This will fail in the CI with the following message:

Loading library prism_es2 from resource failed: 
java.lang.UnsatisfiedLinkError: /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so: Error loading shared library libX11.so.6: No such file or directory (needed by /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so)
java.lang.UnsatisfiedLinkError: /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so: Error loading shared library libX11.so.6: No such file or directory (needed by /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so)
    at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
    at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:321)
...


The tests still run and work regardless, but I wonder if this can be disabled. If not, if that's a feasible enhancement for headless tests?
Thoughts?

-- Marius

From kevin.rushforth at oracle.com  Wed Oct  8 11:53:45 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 8 Oct 2025 04:53:45 -0700
Subject: Headless Tests in CI try to load shared libraries
In-Reply-To: 
References: 
Message-ID: <5bd2cbba-0684-41ea-a06f-0984a38fdd0b@oracle.com>

The headless platform also requires you to use the "sw" pipeline, so: 
`java -Dglass.platform=Headless -Dprism.order=sw`. Note that 
build.gradle does this when running the headless tests, e.g., when 
-PHEADLESS_TEST=true or when running javafx.web tests regardless:

         // Run web tests in headless mode
         systemProperty 'glass.platform', 'Headless'
         systemProperty 'prism.order', 'sw'

It might be reasonable to consider forcing "sw" if 
glass.platform=Headless, but that would require PrismSettings to look 
for this glass property as Prism is initialized first.

-- Kevin


On 10/8/2025 1:00 AM, Marius Hanl wrote:
> Hi,
>
> I recently tried to write headless tests by utilizing the new headless platform.
> First of all, works great!
>
> I noticed that the CI still tries to load shared libraries. This will fail in the CI with the following message:
>
> Loading library prism_es2 from resource failed:
> java.lang.UnsatisfiedLinkError: /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so: Error loading shared library libX11.so.6: No such file or directory (needed by /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so)
> java.lang.UnsatisfiedLinkError: /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so: Error loading shared library libX11.so.6: No such file or directory (needed by /root/.openjfx/cache/26-ea+7/amd64/libprism_es2.so)
>      at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
>      at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:321)
> ...
>
>
> The tests still run and work regardless, but I wonder if this can be disabled. If not, if that's a feasible enhancement for headless tests?
> Thoughts?
>
> -- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From arapte at openjdk.org  Wed Oct  8 13:55:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 8 Oct 2025 13:55:29 GMT
Subject: Integrated: 8365577: Revert to OpenGL as the default JavaFX rendering
 pipeline for macOS
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 13:25:09 GMT, Ambarish Rapte  wrote:

> On macOS, the default rendering pipeline was temporarily set to Metal.
> This change reverts it to es2, by simply reverting the commit fa2127cb3a3fc11238c5c8ce4cf0d15c4000f05c for [JDK-8365576](https://bugs.openjdk.org/browse/JDK-8365576): Temporarily make Metal the default JavaFX rendering pipeline for macOS

This pull request has now been integrated.

Changeset: eb3fcc72
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/eb3fcc72e6be3560cc320ea85dc38c96d2536a53
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8365577: Revert to OpenGL as the default JavaFX rendering pipeline for macOS

Reviewed-by: angorya, kcr, jdv

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

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

From kcr at openjdk.org  Wed Oct  8 15:27:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Oct 2025 15:27:30 GMT
Subject: RFR: 8368879: Intermittent crash on exit when disposing
 MTLRTTextureData
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Oct 2025 04:47:10 GMT, Ambarish Rapte  wrote:

> **Issue**:
> Intermittent crash on exit in `MTLRTTextureData::dispose()` during toolkit shutdown
> The crash is very rare and difficult to reproduce.
> 
> **Cause**:
> While exiting an app, in `MTLContext.dispose()`, a Texture is released **after** the native peer MetalConext is disposed.
> - MTLContext.dispose() method:
> 
>     @Override
>     public void dispose() {
>         nRelease(pContext);
>         state = null;
>         super.dispose();
>     }
> 
> 
> 1. The `MTLContext.dispose()` method releases the native peer (`nRelease(pContext)`) before calling `super.dispose()` (i.e., `BaseShaderContext.dispose()`).
> 2. `BaseShaderContext.dispose()` calls `disposeLCDBuffer()` to dispose the LCD texture, which in turn invokes `MTLRTTextureData::dispose()`
> => As native MetalContext is already disposed, it causes a crash.
> 
> **Fix**:
> Call `disposeLCDBuffer()` before `nRelease(pContext)`. so that the Texture is released **before** disposing the native peer MetalContext.
> The scenario is very rare to reproduce, so no test is added.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1931#pullrequestreview-3315397389

From kcr at openjdk.org  Wed Oct  8 17:22:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Oct 2025 17:22:20 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen
Message-ID: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>

This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).

We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.

### Notes to reviewers:

The following changes are implemented:

* Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
* A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
* When an owner window is closed, all child windows are recursively closed.
* When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
* When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space

Testing:

* Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
* You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
* MonkeyTester also has some dialog tests that can be used to verify the behavior

NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.

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

Commit messages:
 - Remove or comment out log messages
 - 8252373: [macOS] Stage with owner disappears when moved to another screen

Changes: https://git.openjdk.org/jfx/pull/1932/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1932&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8252373
  Stats: 235 lines in 5 files changed: 207 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jfx/pull/1932.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1932/head:pull/1932

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

From kcr at openjdk.org  Wed Oct  8 17:22:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Oct 2025 17:22:20 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen
In-Reply-To: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
Message-ID: 

On Wed, 8 Oct 2025 13:57:16 GMT, Kevin Rushforth  wrote:

> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
> 
> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
> 
> ### Notes to reviewers:
> 
> The following changes are implemented:
> 
> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
> * When an owner window is closed, all child windows are recursively closed.
> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
> 
> Testing:
> 
> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
> * MonkeyTester also has some dialog tests that can be used to verify the behavior
> 
> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.

Reviewers: @andy-goryachev-oracle @beldenfox @arapte 

Cc: @FlorianKirmaier @jperedadnr

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3382512801

From kcr at openjdk.org  Wed Oct  8 18:17:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Oct 2025 18:17:11 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
Message-ID: 

> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
> 
> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
> 
> ### Notes to reviewers:
> 
> The following changes are implemented:
> 
> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
> * When an owner window is closed, all child windows are recursively closed.
> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
> 
> Testing:
> 
> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
> * MonkeyTester also has some dialog tests that can be used to verify the behavior
> 
> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.

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

 - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
 - Remove or comment out log messages
 - 8252373: [macOS] Stage with owner disappears when moved to another screen

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1932/files
  - new: https://git.openjdk.org/jfx/pull/1932/files/c011e198..5c1dcb2f

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

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

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

From kizune at openjdk.org  Wed Oct  8 20:16:21 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Oct 2025 20:16:21 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v3]
In-Reply-To: 
References: 
Message-ID: 

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

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

  Caching children list;
  Use nil instead of NULL;

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1927/files
  - new: https://git.openjdk.org/jfx/pull/1927/files/fe7d12bc..ef936ade

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

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

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

From kizune at openjdk.org  Wed Oct  8 20:46:12 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Oct 2025 20:46:12 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
Message-ID: 

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

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

  Cover the case when menu item has children but it does not respond to the accessibilityValue selector;

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1927/files
  - new: https://git.openjdk.org/jfx/pull/1927/files/ef936ade..7e83d9bd

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

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

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

From kizune at openjdk.org  Wed Oct  8 20:46:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Oct 2025 20:46:14 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <0sHXynKf40NSE5EhQbmUFkFDPhWajqspCATPf_tAfgA=.69d5859f-922d-4e10-b832-33a54298caac@github.com>

On Tue, 7 Oct 2025 12:18:28 GMT, Ambarish Rapte  wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore CHECK_MENU_ITEM binding
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXMenuItemAccessibility.m line 46:
> 
>> 44:         }
>> 45:     }
>> 46:     return [super accessibilityTitle];
> 
> A couple recommendations for this method: 
> 1. Use `nil` instead of `NULL`
> 2. Store `[super accessibilityChildren]` locally
> 
> 
> - (NSString * _Nullable)accessibilityLabel {
>     NSString *accTitle = [super accessibilityTitle];
>     if (accTitle != nil) {
>         return accTitle;
>     }
> 
>     NSArray *accChildren = [super accessibilityChildren];
>     if (accChildren != nil && accChildren.count != 0) {
>         id child0 = accChildren[0];
>         if ([child0 respondsToSelector:@selector(accessibilityValue)]) {
>             return [child0 accessibilityValue];
>         }
>     } else {
>         return @"";
>     }
>     return nil;
> }

Makes sense. I updated the pull request.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2414991778

From jbhaskar at openjdk.org  Thu Oct  9 03:33:03 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 9 Oct 2025 03:33:03 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
Message-ID: 

WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into webkitglib-2.48.7
 - update webkit to 2.48.7
 - Update webkit 2.48.6

Changes: https://git.openjdk.org/jfx/pull/1933/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1933&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367578
  Stats: 227 lines in 41 files changed: 141 ins; 37 del; 49 mod
  Patch: https://git.openjdk.org/jfx/pull/1933.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1933/head:pull/1933

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

From duke at openjdk.org  Thu Oct  9 04:22:23 2025
From: duke at openjdk.org (notzed)
Date: Thu, 9 Oct 2025 04:22:23 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao  wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

Nice, I (Michael Z) can confirm it fixes the frame throttling here, although in a simple animation all rendered frames have a pulse-presentation latency of 33ms -- which is somewhat better than the 48ms previously.

I've been doing some testing of the pulse-presentation latency, taking timestamps of the start of the pulse, the end of the render (before glXSwapBuffers), and the GL_TIMESTAMP of when glXSwapBuffers() is processed (via glQueryCounter()).  Plus tracking the pulse number all the way through so they can be matched.  This is some of the output with the patch:

    event                               pulse-submit   present

    pulse 1050 17484397796
    present 1048 17467793037 17484194371  -   +16.697  +33.098
    pulse 1051 17501064359
    present 1049 17484490371 17500860741  -   +16.782  +33.152
    pulse 1052 17517726363
    present 1050 17501155852 17517524593  -   +16.758  +33.127
    pulse 1053 17534403585

(This is in logging order, not temporal)

As a comparison using the existing SwapIntervalSGI and calling glFinish() after all scenes have rendered results in a pulse-presentation latency of 16.7ms instead.  Adding the glFinish() to the SwapIntervalEXT version has no effect.

    pulse 1050 17478236976
    present 1048 17461465333 17461674222  -   +16.569  +16.778
    pulse 1051 17494927765
    present 1049 17478075556 17478273482  -   +16.443  +16.641
    pulse 1052 17511531058
    present 1050 17494771852 17494973482  -   +16.535  +16.737
    pulse 1053 17528240031

??? I don't know why they'd be different given they both have the same order of pulses, but the timing code is the same.

For the curious, [I blogged about the timings I did yesterday](https://www.zedzone.au/post/0199c6c0edb7), I haven't added any plots with this patch but they look the same as "Build 2" but with another frame of latency to the present times (around 33 vs 16-17ms).

> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.

Well if prism.vsync=false it wont call swapinterval and will just run at the pulse rate, plus there's javafx.animation.fullspeed?

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3384029282

From jdv at openjdk.org  Thu Oct  9 07:01:28 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 9 Oct 2025 07:01:28 GMT
Subject: RFR: 8368879: Intermittent crash on exit when disposing
 MTLRTTextureData
In-Reply-To: 
References: 
Message-ID: 

On Wed, 8 Oct 2025 04:47:10 GMT, Ambarish Rapte  wrote:

> **Issue**:
> Intermittent crash on exit in `MTLRTTextureData::dispose()` during toolkit shutdown
> The crash is very rare and difficult to reproduce.
> 
> **Cause**:
> While exiting an app, in `MTLContext.dispose()`, a Texture is released **after** the native peer MetalConext is disposed.
> - MTLContext.dispose() method:
> 
>     @Override
>     public void dispose() {
>         nRelease(pContext);
>         state = null;
>         super.dispose();
>     }
> 
> 
> 1. The `MTLContext.dispose()` method releases the native peer (`nRelease(pContext)`) before calling `super.dispose()` (i.e., `BaseShaderContext.dispose()`).
> 2. `BaseShaderContext.dispose()` calls `disposeLCDBuffer()` to dispose the LCD texture, which in turn invokes `MTLRTTextureData::dispose()`
> => As native MetalContext is already disposed, it causes a crash.
> 
> **Fix**:
> Call `disposeLCDBuffer()` before `nRelease(pContext)`. so that the Texture is released **before** disposing the native peer MetalContext.
> The scenario is very rare to reproduce, so no test is added.

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1931#pullrequestreview-3317465607

From duke at openjdk.org  Thu Oct  9 07:43:37 2025
From: duke at openjdk.org (notzed)
Date: Thu, 9 Oct 2025 07:43:37 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 4 Oct 2025 15:19:32 GMT, Thiago Milczarek Sayao  wrote:

>> As Michael Zucchi pointed out on the mailing list, the high framerate occurs because `glXSwapBuffers() `operates asynchronously. To ensure proper synchronization, you can call `glFinish() `afterward, which blocks until the buffer swap is fully completed. However, when using `glXSwapIntervalSGI`, the swap interval setting applies globally rather than per drawable. In contrast, `glXSwapIntervalEXT` provides per-drawable control, allowing finer-grained vsync behavior.
>> 
>> I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
>> 
>> See [https://wikis.khronos.org/opengl/Swap_Interval](https://wikis.khronos.org/opengl/Swap_Interval)
>> 
>> It also selects the correct visual for transparency which needs to be depth = 32 for X11.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call glXSwapIntervalEXT or glXSwapIntervalSGI if not null

Sorry I was wrong and should've tested with more than 1 window.  The change to glXSwapIntervalEXT() doesn't work properly and behaves as if glFinish() is called for each window after glXSwapBuffer(), each causing a new wait for vblank.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3384559383

From lkostyra at openjdk.org  Thu Oct  9 09:17:51 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 9 Oct 2025 09:17:51 GMT
Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 9 Oct 2025 04:01:52 GMT, notzed  wrote:

> > I don't know if there are scenarios when the unlimited frame rate is needed - if so we should provide a option.
> 
> Well if prism.vsync=false it wont call swapinterval and will just run at the pulse rate, plus there's javafx.animation.fullspeed?

`javafx.animation.fullspeed=true` has the same effect as `prism.vsync=false` and more. [Both disable vsync](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java#L118) in order to uncap the framerate from monitor's refresh rate, and in addition to that, `javafx.animation.fullspeed=true` also [sets the pulse timer to immediately trigger the next pulse](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java#L263).

While not applicable during day-to-day JavaFX use, unlimited framerate can actually be quite useful. We currently actively use `javafx.animation.fullspeed=true` when working on Metal and D3D12 to do performance and stability testing. It would be good to keep it around and functional on Linux as well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1929#issuecomment-3384928497

From arapte at openjdk.org  Thu Oct  9 10:08:25 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 9 Oct 2025 10:08:25 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 20:46:12 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover the case when menu item has children but it does not respond to the accessibilityValue selector;

LGTM, With a minor query. 
I shall re-approve if query results in a change.

modules/javafx.graphics/src/main/native-glass/mac/a11y/JFXMenuItemAccessibility.m line 46:

> 44:         return @"";
> 45:     }
> 46:     return title;

Minor query: Is `return @""` statement required ? Cant' we rely on `return title;` (which would return nil in case) ?

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1927#pullrequestreview-3318173968
PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2416246855

From arapte at openjdk.org  Thu Oct  9 11:48:33 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 9 Oct 2025 11:48:33 GMT
Subject: Integrated: 8368879: Intermittent crash on exit when disposing
 MTLRTTextureData
In-Reply-To: 
References: 
Message-ID: <7kTao6ds31q3GakU85cgBn08SWCQV8MRADEHdBnwq5Q=.a9c30ab6-91a8-4220-9fe8-31cfc9967022@github.com>

On Wed, 8 Oct 2025 04:47:10 GMT, Ambarish Rapte  wrote:

> **Issue**:
> Intermittent crash on exit in `MTLRTTextureData::dispose()` during toolkit shutdown
> The crash is very rare and difficult to reproduce.
> 
> **Cause**:
> While exiting an app, in `MTLContext.dispose()`, a Texture is released **after** the native peer MetalConext is disposed.
> - MTLContext.dispose() method:
> 
>     @Override
>     public void dispose() {
>         nRelease(pContext);
>         state = null;
>         super.dispose();
>     }
> 
> 
> 1. The `MTLContext.dispose()` method releases the native peer (`nRelease(pContext)`) before calling `super.dispose()` (i.e., `BaseShaderContext.dispose()`).
> 2. `BaseShaderContext.dispose()` calls `disposeLCDBuffer()` to dispose the LCD texture, which in turn invokes `MTLRTTextureData::dispose()`
> => As native MetalContext is already disposed, it causes a crash.
> 
> **Fix**:
> Call `disposeLCDBuffer()` before `nRelease(pContext)`. so that the Texture is released **before** disposing the native peer MetalContext.
> The scenario is very rare to reproduce, so no test is added.

This pull request has now been integrated.

Changeset: 1b16ebaa
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/1b16ebaa8c583ce6094ad5717969967b8c9f2c9e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8368879: Intermittent crash on exit when disposing MTLRTTextureData

Reviewed-by: kcr, jdv

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

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

From kcr at openjdk.org  Thu Oct  9 12:14:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Oct 2025 12:14:44 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 03:21:20 GMT, Jay Bhaskar  wrote:

> WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.

@tiainen This is a fairly small update to WebKit. Do you want to do a test build before we integrate it? If not, that's OK.

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

PR Comment: https://git.openjdk.org/jfx/pull/1933#issuecomment-3385587532

From mariushanl at web.de  Thu Oct  9 12:59:06 2025
From: mariushanl at web.de (Marius Hanl)
Date: Thu, 9 Oct 2025 12:59:06 +0000
Subject: Headless Tests in CI try to load shared libraries
In-Reply-To: <5bd2cbba-0684-41ea-a06f-0984a38fdd0b@oracle.com>
References: 
 <5bd2cbba-0684-41ea-a06f-0984a38fdd0b@oracle.com>
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From kizune at openjdk.org  Thu Oct  9 15:39:15 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 9 Oct 2025 15:39:15 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 9 Oct 2025 10:05:04 GMT, Ambarish Rapte  wrote:

> Minor query: Is `return @""` statement required ? Cant' we rely on `return title;` (which would return nil in case) ?

Yes, otherwise on menu item with no accessibility title it will report "Menu separator". Since right now VoiceOver is not able to put focus on real menu separator item even with the VO shortcuts (i think Apple broke it in macOS 11) it can only confuse user.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1927#discussion_r2417171725

From duke at openjdk.org  Thu Oct  9 17:19:10 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 9 Oct 2025 17:19:10 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
References: 
 <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
Message-ID: 

On Tue, 30 Sep 2025 23:31:20 GMT, Pabulaner IV  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 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

Thanks for the detailed feedback, much appreciated. So as far as I understood Your feedback it means that the PR from Your side would be good to go, but maybe in the future some minor bug / issue fixes would be nice to have?

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3386824030

From angorya at openjdk.org  Thu Oct  9 19:39:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Oct 2025 19:39:29 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Notice to testers/reviewers:
I've updated the Stage Page in the Monkey Tester to cover additional initialization options such as placing the newly created stage outside of any Screen.

https://github.com/andy-goryachev-oracle/MonkeyTest

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3387249991

From angorya at openjdk.org  Thu Oct  9 20:19:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Oct 2025 20:19:26 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 8 Oct 2025 20:46:12 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover the case when menu item has children but it does not respond to the accessibilityValue selector;

I might have found a weird regression (using the monkey tester).

To reproduce:
- open the menu bar page
- turn on the Voice Over
- click on a menu in the inner MenuBar, down arrow until the last submenu
- press SPACE to open the submenu
- the VO announces "you are on blah blah, to select this menu press control-option-space"
- press control-option-space

What I see is that somehow both the main menu and the inner menu bar are activated.  LEFT/RIGHT arrow keys result in both menu bars selection changing, etc.  This does not happen in the master branch (it does not seem to mention the control-option-space):


Screenshot 2025-10-09 at 13 09 19

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3387362899

From kcr at openjdk.org  Thu Oct  9 21:28:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Oct 2025 21:28:36 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 03:21:20 GMT, Jay Bhaskar  wrote:

> WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.

My testing looks good.

As for the changes themselves, I added one inline comment about a change that seems unnecessary, in that it didn't come from upstream. The file in question, `Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp`, was not modified between 2.48.5 and 2.48.7.

Conversely, I see one file that _was_ modified upstream between 2.48.5 and 2.48.7 for which you didn't pick up the changes:


Source/cmake/OptionsGTK.cmake


Was this intentional or was it missed? I realize that we probably don't use it in our build, but we updated this for WebKit 622.1, so I would have expected to see it updated here.

modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 91:

> 89:     return result != Z_OK && result != Z_STREAM_END && result != Z_BUF_ERROR;
> 90: #endif
> 91:     return true;

I don't understand this change. It didn't come from upstream, since this file wasn't changed in the upstream code between 2.48.5 and 2.48.7?

I'm surprised that removing this return statement didn't cause a compilation failure for the `PLATFORM(JAVA)` case (i.e., for JavaFX), but somehow doesn't. Possibly it is just being treated as a warning rather than an error.

I recommend to revert this change (i.e., revert this file).

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

PR Review: https://git.openjdk.org/jfx/pull/1933#pullrequestreview-3320119361
PR Review Comment: https://git.openjdk.org/jfx/pull/1933#discussion_r2417588372

From angorya at openjdk.org  Thu Oct  9 21:46:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Oct 2025 21:46:25 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
Message-ID: <-kirXbuStTpx3Uzq3PWdMkX8vk6OnmEY43Mu8eQ1elY=.e07f3dad-0ea7-41bc-ae0f-5f14e045abd1@github.com>

On Wed, 8 Oct 2025 20:46:12 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cover the case when menu item has children but it does not respond to the accessibilityValue selector;

Could you also sync up with the master branch please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3387579445

From angorya at openjdk.org  Thu Oct  9 22:37:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Oct 2025 22:37:15 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Interesting observation (separate spaces=enabled): when I create a non-modal, ownerless window with alwaysOnTop=true, I cannot see it in the mission control (fn+F3) view.  Turn off alwaysOnTop and it appears.

Happens with the master branch, so it might be pre-existing or even a desired behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3387688243

From kcr at openjdk.org  Thu Oct  9 23:08:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Oct 2025 23:08:17 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Definitely preexisting. JavaFX glass uses `NSFloatingWindowLevel` for always-on-top windows, for which the macOS docs helpfully say "Useful for floating palettes", without actually describing what that means. I suspect that has the effect of excluding it from Mission Control's list of windows.

That wouldn't have changed with this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3387737808

From angorya at openjdk.org  Thu Oct  9 23:13:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Oct 2025 23:13:22 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

My testing looks good (macOS 15.7.1 M1).
With and without separate spaces, with various combinations of modality, ownership, iconified/maximized/fullscreen, and target locations - though I did not test _every_ combination.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1932#pullrequestreview-3320883981

From jpereda at openjdk.org  Fri Oct 10 09:31:26 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 10 Oct 2025 09:31:26 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform
Message-ID: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>

This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

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

Commit messages:
 - Implement invokeAndWait and finishTerminating on headless platform, including tests

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

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

From kcr at openjdk.org  Fri Oct 10 11:55:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 11:55:24 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: 

On Fri, 10 Oct 2025 09:25:39 GMT, Jose Pereda  wrote:

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

I left a recommendation to also set `"prism.order"` to `"sw"` as discussed in [this mailing list thread](https://mail.openjdk.org/pipermail/openjfx-dev/2025-October/056676.html) and a couple other minor comments.

tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication1Test.java line 45:

> 43:     @BeforeAll
> 44:     public static void setup() throws Exception {
> 45:         System.setProperty("glass.platform", "Headless");

I recommend also setting `"prism.order=sw"`.

tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication1Test.java line 57:

> 55:             assertTrue(Platform.isFxApplicationThread());
> 56:             new Thread(() -> {
> 57:                 assertFalse(Platform.isFxApplicationThread());

Btw, an Exception or Error in this thread won't propagate to the test runner, so if this assertion ever fails it would print the exception, but not cause the test to fail. The test will timeout anyway if this happens, so it should be fine.

tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 39:

> 37:     @BeforeAll
> 38:     public static void setup() throws Exception {
> 39:         System.setProperty("glass.platform", "Headless");

I recommend also setting `"prism.order=sw"`.

tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 49:

> 47:             Platform.runLater(Platform::exit);
> 48:         });
> 49:         Util.sleep(10);

Is 10msec enough?

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

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3322867205
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419651998
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419668916
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419675588
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419685540

From jbhaskar at openjdk.org  Fri Oct 10 12:07:46 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 10 Oct 2025 12:07:46 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.

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

  adding review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1933/files
  - new: https://git.openjdk.org/jfx/pull/1933/files/c54d91fa..c6edc7bf

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

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

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

From jbhaskar at openjdk.org  Fri Oct 10 12:07:49 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 10 Oct 2025 12:07:49 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 9 Oct 2025 18:12:46 GMT, Kevin Rushforth  wrote:

>> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding review comments
>
> modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 91:
> 
>> 89:     return result != Z_OK && result != Z_STREAM_END && result != Z_BUF_ERROR;
>> 90: #endif
>> 91:     return true;
> 
> I don't understand this change. It didn't come from upstream, since this file wasn't changed in the upstream code between 2.48.5 and 2.48.7?
> 
> I'm surprised that removing this return statement didn't cause a compilation failure for the `PLATFORM(JAVA)` case (i.e., for JavaFX), but somehow doesn't. Possibly it is just being treated as a warning rather than an error.
> 
> I recommend to revert this change (i.e., revert this file).

we do not use OptionsGTK.cmake, but i think it missed , added to be in sync
return true; is added now

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1933#discussion_r2419737806

From jpereda at openjdk.org  Fri Oct 10 12:45:10 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 10 Oct 2025 12:45:10 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v2]
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: 

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Process feedback from reviewer

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1934/files
  - new: https://git.openjdk.org/jfx/pull/1934/files/38128453..bcf70f38

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

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

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

From jpereda at openjdk.org  Fri Oct 10 12:56:02 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 10 Oct 2025 12:56:02 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: 

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Process feedback from reviewer

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1934/files
  - new: https://git.openjdk.org/jfx/pull/1934/files/bcf70f38..47a450a6

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

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

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

From jpereda at openjdk.org  Fri Oct 10 12:56:07 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 10 Oct 2025 12:56:07 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 11:43:44 GMT, Kevin Rushforth  wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process feedback from reviewer
>
> tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication1Test.java line 45:
> 
>> 43:     @BeforeAll
>> 44:     public static void setup() throws Exception {
>> 45:         System.setProperty("glass.platform", "Headless");
> 
> I recommend also setting `"prism.order=sw"`.

Done

> tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication1Test.java line 57:
> 
>> 55:             assertTrue(Platform.isFxApplicationThread());
>> 56:             new Thread(() -> {
>> 57:                 assertFalse(Platform.isFxApplicationThread());
> 
> Btw, an Exception or Error in this thread won't propagate to the test runner, so if this assertion ever fails it would print the exception, but not cause the test to fail. The test will timeout anyway if this happens, so it should be fine.

Right, I've moved the other assert before the count down, so if that one fails, it times out as well.

> tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 39:
> 
>> 37:     @BeforeAll
>> 38:     public static void setup() throws Exception {
>> 39:         System.setProperty("glass.platform", "Headless");
> 
> I recommend also setting `"prism.order=sw"`.

Done

> tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 49:
> 
>> 47:             Platform.runLater(Platform::exit);
>> 48:         });
>> 49:         Util.sleep(10);
> 
> Is 10msec enough?

I'm testing on an M1, but you are right, on different environments it could take longer.

I've added now an exit latch from `PlatformImplShim.test_getPlatformExitLatch()`, so we wait whatever is needed until `PlatformImpl.tkExit()` finishes, and then those 10 ms should be more than enough (but we still need to wait a couple of ms nonetheless until the JavaFX thread is fully gone).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419937376
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2420000718
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419938352
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2419959876

From kcr at openjdk.org  Fri Oct 10 13:48:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 13:48:17 GMT
Subject: RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <45JAAXN8Vw1RjrO-LlOiCl7GyzoSwpwtKde-XAN1ctE=.eaa46d4a-5529-4a6f-ac80-55083f35aeec@github.com>

On Fri, 10 Oct 2025 12:07:46 GMT, Jay Bhaskar  wrote:

>> WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding review comments

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1933#pullrequestreview-3323640341

From kcr at openjdk.org  Fri Oct 10 14:25:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 14:25:24 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 12:56:02 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback from reviewer

LGTM. The two new tests fail without the fix and pass with the fix.

Wait for 1 business day (so, Monday some time) to give others a change to review. In particular @johanvos might want to look at it.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3323894035

From kcr at openjdk.org  Fri Oct 10 14:46:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 14:46:24 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v4]
In-Reply-To: <66UNFMkz_KKoxZKXKwEcOZr4Ep2_69kKlrQJNSsLmbc=.62b1f605-6aa3-4916-829b-3160e4f7dd6e@github.com>
References: 
 
 <66UNFMkz_KKoxZKXKwEcOZr4Ep2_69kKlrQJNSsLmbc=.62b1f605-6aa3-4916-829b-3160e4f7dd6e@github.com>
Message-ID: 

On Fri, 22 Aug 2025 10:41:49 GMT, John Hendrikx  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> Thanks for all the input.  I think there are now two ways to proceed:
> 
> 1. Leave it as is, including the new `backgroundLoading` variants for `InputStream`, but document clearly for both the old and new constructors when the stream will be closed (ie. only when `backgroundLoading` is `true` we will close the stream).
> 
> 2. Don't add these new constructors, but add a more obvious variant with `Supplier`, where the ownership is more clear, with the caller of the supplier owning the stream created.
> 
> I get the impression the consensus leans towards option 1.  I don't see a direct compelling need for the `Supplier` variant, although I'm happy to provide an implementation if option 2 is favored.

@hjohn In case you missed it, the spec changes for this are almost ready, pending your reply to my feedback about the wording in a few places and the creation of the CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3390549694

From angorya at openjdk.org  Fri Oct 10 14:52:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Oct 2025 14:52:19 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>

On Fri, 10 Oct 2025 12:56:02 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback from reviewer

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 66:

> 64:     void stopProcessing() {
> 65:         for (RunLoopEntry entry : activeRunLoops) {
> 66:             runnableQueue.add(() -> entry.active = false);

I would highly recommend declaring `RunLoopEntry.active` `volatile`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2420628403

From kcr at openjdk.org  Fri Oct 10 15:02:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 15:02:01 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
 
 
Message-ID: <3o9Fl1djD20rF5DrE4MOvVrWJKsIrW5VNM1MPVXvIX0=.3ad7ebe1-ee2a-456d-8a41-a8f6594a5175@github.com>

On Fri, 15 Aug 2025 20:06:50 GMT, Martin Fox  wrote:

>> The issue is that the Java side updates the property first, and only afterward requests the Glass native side to apply the change. I've found this to cause many problems and I fixed the same way in  #1789 - when the change can't be applied, it notifies back.
>
>> Could this lead to two resize commands in some cases?
> 
> Yes, I was trying not to be too clever with my checks. I figured if the second notification wasn't necessary it would be benign. At the very least it won't trigger invalidation of the window's width and height properties.
> 
> I will tighten this up since I have to tweak the code a bit anyway. I just verified that on Windows you can alter the size of a maximized window and the OS will keep it in the MAXIMIZED state (as it resizes glass calls notifyResize with WindowEvent.MAXIMIZED). This PR can kick the window out of the MAXIMIZED or MINIMIZED state incorrectly. Unfortunately it puts the window in the wrong internal state without updating the maximized or iconified properties so it's not easy to write a test to detect this.

This is pending work from you, right? I'll put it back on my review queue once you make the changes you mentioned above.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2420694955

From jhendrikx at openjdk.org  Fri Oct 10 15:04:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Oct 2025 15:04:23 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v6]
In-Reply-To: 
References: 
Message-ID: 

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

 - Clarify docs
 - Fix formatting

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1875/files
  - new: https://git.openjdk.org/jfx/pull/1875/files/6494c52a..158d1781

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

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

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

From angorya at openjdk.org  Fri Oct 10 15:04:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Oct 2025 15:04:24 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 15:00:54 GMT, John Hendrikx  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 two additional commits since the last revision:
> 
>  - Clarify docs
>  - Fix formatting

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1875#pullrequestreview-3324108852

From jhendrikx at openjdk.org  Fri Oct 10 15:04:26 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Oct 2025 15:04:26 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 23 Aug 2025 14:26:51 GMT, John Hendrikx  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

Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3390637438

From jhendrikx at openjdk.org  Fri Oct 10 15:04:28 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Oct 2025 15:04:28 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 30 Sep 2025 16:17:28 GMT, Kevin Rushforth  wrote:

>> 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/javafx/scene/image/Image.java line 625:
> 
>> 623:      * 

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

You're right, that is clearer, fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2420663526

From kcr at openjdk.org  Fri Oct 10 15:22:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 15:22:22 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 10 Oct 2025 15:00:54 GMT, John Hendrikx  wrote:

> Just to be sure, the CSR required here is for the newly added constructors? The documentation changes on the existing constructors are only clarifications, no functionality was changed.

Technically not needed, but it wouldn't hurt to include them in the CSR as long as you are filing a CSR anyway.

The doc changes look good to me now.

One more thing: Can you merge in the lastest master? Your source branch is quite out of date.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3390730124

From jhendrikx at openjdk.org  Fri Oct 10 15:55:07 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Oct 2025 15:55:07 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v7]
In-Reply-To: 
References: 
Message-ID: 

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

 - Merge branch 'openjdk:master' into feature/image-constructor
 - Clarify docs
 - Fix formatting
 - Clarify documentation with regards to stream closing
 - Fix typo
 - Add links to progress property in javadoc
 - Remove wrapping
 - Add since tags
 - 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 max exceed 2 GB
   - Improved documentation of Image regarding background loading

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1875/files
  - new: https://git.openjdk.org/jfx/pull/1875/files/158d1781..71ab9921

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

  Stats: 149633 lines in 1239 files changed: 80962 ins; 26832 del; 41839 mod
  Patch: https://git.openjdk.org/jfx/pull/1875.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1875/head:pull/1875

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

From kcr at openjdk.org  Fri Oct 10 17:32:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 17:32:19 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
References: 
 <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
Message-ID: 

On Tue, 30 Sep 2025 23:31:20 GMT, Pabulaner IV  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 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

This is a very preliminary review. I haven't run it yet, but I will soon. I left a few inline comments of things I happened to spot.

The fix itself looks good to me. 

The test framework and set of tests looks fine on first glance, but I haven't looked at them in detail. I will do so, along with running them

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.h line 70:

> 68:     // This is used to allow JFX to install its own system menu
> 69:     // without interfering with the hosting application.
> 70:     NSMenu* hostMenu;

Minor: align the field name to match the rest of the fields in this file

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuJFXPanelSwingFirstTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2017, 2024, Oracle and/or its affiliates. All rights reserved.

Replace `2024` with `2025`. Also, unless this file was substantially copied from an existing file (which it doesn't look like it was), remove the `2017,`.

This applies to all of the new files.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuJFXPanelSwingFirstTest.java line 25:

> 23:  * questions.
> 24:  */
> 25: package test.javafx.stage;

I recommend moving these tests to a new package, perhaps `test.com.sun.glass.ui.mac`, since this is testing macOS glass functionality.

Or maybe, `test.robot...`, since even though they aren't robot tests, they rely on Window focus working.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuTestBase.java line 1:

> 1: package test.javafx.stage;

This needs a copyright header block.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuTestBase.java line 32:

> 30: import javax.swing.SwingUtilities;
> 31: 
> 32: import org.junit.jupiter.api.Test;

This is an unused import and should be removed. Especially since if there ever were a method in this class annotated with `@Test` it wouldn't work correctly since the tests in this test group are written so that there can be no more than one `@Test` in a test class, including its superclasses.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuTestBase.java line 146:

> 144:     /// Helpers for creation and focusing of windows
> 145:     ///
> 146:     /////////////////////////////////////////////////////////

Using `///` is reserved for markdown style javadoc comments. Replace this with something else.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuTestBase.java line 406:

> 404:     /// Helpers for synchronization
> 405:     ///
> 406:     /////////////////////////////////////////////////////////

Replace `///` with something else.

tests/system/src/test/java/test/javafx/stage/MacOSSystemMenuTestBase.java line 422:

> 420:     }
> 421: 
> 422:     protected void sleep(long millis) {

This is unused, and duplicates the functionality of `Util.sleep` anyway. I recommend to remove it.

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

PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3324402471
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2420935478
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2420944384
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421005431
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421290204
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421333115
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421304289
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421321910
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2421314423

From kcr at openjdk.org  Fri Oct 10 17:52:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 17:52:55 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 15:55:07 GMT, John Hendrikx  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 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 nine additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into feature/image-constructor
>  - Clarify docs
>  - Fix formatting
>  - Clarify documentation with regards to stream closing
>  - Fix typo
>  - Add links to progress property in javadoc
>  - Remove wrapping
>  - Add since tags
>  - 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 max exceed 2 GB
>    - Improved documentation of Image regarding background loading

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1875#pullrequestreview-3325029011

From kcr at openjdk.org  Fri Oct 10 17:52:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 17:52:56 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 15:19:14 GMT, Kevin Rushforth  wrote:

>> Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.
>
>> Just to be sure, the CSR required here is for the newly added constructors? The documentation changes on the existing constructors are only clarifications, no functionality was changed.
> 
> Technically not needed, but it wouldn't hurt to include them in the CSR as long as you are filing a CSR anyway.
> 
> The doc changes look good to me now.
> 
> One more thing: Can you merge in the lastest master? Your source branch is quite out of date.

> @kevinrushforth requested review from ... @andy-goryachev-oracle now

You can ignore this. My request crossed your re-review

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3391511061

From angorya at openjdk.org  Fri Oct 10 18:02:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Oct 2025 18:02:37 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 17:49:46 GMT, Kevin Rushforth  wrote:

> You can ignore this. My request crossed your re-review

race condition: the review was loading in the background from an InputStream /jk

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3391560718

From kevin.rushforth at oracle.com  Fri Oct 10 19:26:17 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Oct 2025 12:26:17 -0700
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
 <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>
Message-ID: <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>

I informally polled a few folks in the core libs group. They haven't 
started using it in the JDK yet, but would consider it primarily for new 
classes; some felt as Michael did that mixing styles in the same class 
would be annoying.

I can see the argument for consistency, especially in a file like Node 
or Control, where we have many existing properties and other methods. 
For additions of a new property or method in such a file, consistency 
seems more important than being able to use markdown.

In cases where there aren't so many methods, or where you are already 
modifying many of them, it might be reasonable to use markdown for new 
or modified methods.

Perhaps as a compromise, we could consider allowing for new classes and 
classes where you are modifying a large percentage of the existing docs 
anyway, but in general, avoid using markdown in existing classes.

Concretely, that would mean asking Nir to update PR 1873 [1] to not use 
markdown-style doc comments (it seems gratuitous there anyway, since it 
isn't using any markdown syntax), but allow the use of markdown in PR 
1880 [2].

Thoughts?

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1873
[2] https://github.com/openjdk/jfx/pull/1880


On 10/7/2025 6:33 AM, John Hendrikx wrote:
> I'm of the same mind.? I don't see a use case for markdown comments at
> all in a
> project as mature as JavaFX, and I'm unlikely to use them, even for new
> files simply to be
> more consistent with other existing files (and I may copy/paste docs
> sometimes as well).
>
> There are barely any code conventions in FX as it is (indent is?4
> spaces, and general Java naming
> conventions are the only ones that I think of that are consistent
> through-out the project), but
> a consistent Javadoc?style can also be?considered one currently... still.
>
> --John
>
> On 07/10/2025 10:47, Michael Strau? wrote:
>> Markdown comments are not _better_ than HTML comments, they are just
>> different. In particular, I question the unsubstantiated claim that
>> markdown comments are more readable; I've never once struggled with
>> reading HTML comments, especially if you use the recent additions like
>> {@snippet}.
>>
>> I might use markdown comments myself if I were to start a greenfield
>> project. But in a mature project, consistency is more important than
>> (at best) tiny ergonomic improvements. In fact, consistency is one of
>> the most important factors contributing to ergonomy. You point out
>> that you wouldn't want to invite wholesale refactoring, but to be
>> fair, I'd rather have a wholesale refactor to use markdown comments
>> everywhere than be forever annoyed to see two wildly different comment
>> styles next to each other.
>>
>> I've looked at recent CSRs and API additions in the JDK, and haven't
>> found a single one using markdown comments. Why the rush to be the
>> first project to use them?
>>
>> In any case, if we end up allowing markdown comments, I would strongly
>> suggest to only allow a single comment style per file. Mixing both
>> styles in a single file is an unmitigated readability disaster.
>>
>>
>>
>> On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
>>  wrote:
>>> Now that JavaFX requires JDK 24 to build, we can use features from JDK
>>> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
>>> delivered in JDK 23.
>>>
>>> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
>>> proposed changes that do just that.
>>>
>>> As was pointed out in a review comment on PR 1873 [3], we should make a
>>> deliberate decision to start using them and have some guidelines around
>>> doing so.
>>>
>>> To that end, I would propose that developers can start using markdown
>>> javadoc comments in new APIs and in APIs that are modified such that
>>> markdown comments would be helpful.
>>>
>>> This is not an invitation to do wholesale changing of existing javadoc
>>> comments to markdown-style comments for docs that otherwise aren't being
>>> modified.
>>>
>>> Comments are welcome.
>>>
>>> -- Kevin
>>>
>>> [0] https://openjdk.org/jeps/467
>>> [1] https://github.com/openjdk/jfx/pull/1873
>>> [2] https://github.com/openjdk/jfx/pull/1880
>>> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>>>


From kcr at openjdk.org  Fri Oct 10 19:40:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 19:40:22 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: 
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
Message-ID: 

On Sat, 30 Aug 2025 15:46:29 GMT, Nir Lisker  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 looks like a good addition.

I left a comment recommending to revert the markdown-style comments. There doesn't seem to be a good reason to use them for the two new properties and new static final constant.

modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 7714:

> 7712:     }
> 7713: 
> 7714:     public final EventHandler getOnMouseDragDone() {

We normally put the property methods that will inherit the docs below the method (or private property as the case may be) that has the javadoc comments.

I recommend to move these two methods below the `onMouseDragDoneProperty` method.

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

PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3325642083
PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2421880414

From kcr at openjdk.org  Fri Oct 10 19:40:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 19:40:23 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 <7G8Rb7FfNKqLDb8Bz1-dfGtIgOSbkkEfL2aJOWK0ffM=.8ead616b-9b51-4750-b42f-5fa294ad78ef@github.com>
 
Message-ID: <-Gi2vST_TqjGBB1Fz6VFYkAKsd0bw6IhBmfKnRJjoaw=.a1754ba7-d23b-497c-8ef2-ea7a6ed54fdb@github.com>

On Thu, 2 Oct 2025 17:33:05 GMT, Kevin Rushforth  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.
>
> I started a (belated) [discussion on this on the mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2025-October/056578.html). As mentioned in that message, I think using markdown comments is fine for new APIs and docs that are modified in a way that markdown would be helpful.

After reading Michael and John's comments, I informally polled a few folks on the core libs team. I amend my proposal to include a recommendation to avoid mixing styles in a class like Node where there are already a lot of existing properties and you are adding a new one.

For this PR, there doesn't seem to be a good reason to use markdown-style doc comments. I recommend using old-style `/**` block comments for consistency.

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

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

From andy.goryachev at oracle.com  Fri Oct 10 19:43:57 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 10 Oct 2025 19:43:57 +0000
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
 <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>
 <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>
Message-ID: 

I just wanted to say that the platform is evolving, the toolset is evolving, so we might as well evolve where it makes sense technically.

If we talk about "consistency", our code is already inconsistent to begin with.  @Override annotations on the same line vs its own line, switch statements vs switch expressions, line wrapping where there should be no wrapping, newlines added or omitted, final used and not used, null property values allowed and not allowed without documenting, boolean values initialized to false, objects initialized to null and not, and so on and so forth.

So basically, I think that consistency for the sake of consistency is a poor argument.  I would rather let the people decide when they use the new format - in the new code, or in the old code when javadoc changed substantially.  Also, we might want to keep in mind that at the end, publicly visible outcome in the form of the API Spec, is the same in either case.

-andy


From: openjfx-dev  on behalf of Kevin Rushforth 
Date: Friday, October 10, 2025 at 12:26
To: openjfx-dev at openjdk.org 
Subject: Re: Using markdown-style javadoc comments (JEP 467)

I informally polled a few folks in the core libs group. They haven't
started using it in the JDK yet, but would consider it primarily for new
classes; some felt as Michael did that mixing styles in the same class
would be annoying.

I can see the argument for consistency, especially in a file like Node
or Control, where we have many existing properties and other methods.
For additions of a new property or method in such a file, consistency
seems more important than being able to use markdown.

In cases where there aren't so many methods, or where you are already
modifying many of them, it might be reasonable to use markdown for new
or modified methods.

Perhaps as a compromise, we could consider allowing for new classes and
classes where you are modifying a large percentage of the existing docs
anyway, but in general, avoid using markdown in existing classes.

Concretely, that would mean asking Nir to update PR 1873 [1] to not use
markdown-style doc comments (it seems gratuitous there anyway, since it
isn't using any markdown syntax), but allow the use of markdown in PR
1880 [2].

Thoughts?

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1873
[2] https://github.com/openjdk/jfx/pull/1880


On 10/7/2025 6:33 AM, John Hendrikx wrote:
> I'm of the same mind.  I don't see a use case for markdown comments at
> all in a
> project as mature as JavaFX, and I'm unlikely to use them, even for new
> files simply to be
> more consistent with other existing files (and I may copy/paste docs
> sometimes as well).
>
> There are barely any code conventions in FX as it is (indent is 4
> spaces, and general Java naming
> conventions are the only ones that I think of that are consistent
> through-out the project), but
> a consistent Javadoc style can also be considered one currently... still.
>
> --John
>
> On 07/10/2025 10:47, Michael Strau? wrote:
>> Markdown comments are not _better_ than HTML comments, they are just
>> different. In particular, I question the unsubstantiated claim that
>> markdown comments are more readable; I've never once struggled with
>> reading HTML comments, especially if you use the recent additions like
>> {@snippet}.
>>
>> I might use markdown comments myself if I were to start a greenfield
>> project. But in a mature project, consistency is more important than
>> (at best) tiny ergonomic improvements. In fact, consistency is one of
>> the most important factors contributing to ergonomy. You point out
>> that you wouldn't want to invite wholesale refactoring, but to be
>> fair, I'd rather have a wholesale refactor to use markdown comments
>> everywhere than be forever annoyed to see two wildly different comment
>> styles next to each other.
>>
>> I've looked at recent CSRs and API additions in the JDK, and haven't
>> found a single one using markdown comments. Why the rush to be the
>> first project to use them?
>>
>> In any case, if we end up allowing markdown comments, I would strongly
>> suggest to only allow a single comment style per file. Mixing both
>> styles in a single file is an unmitigated readability disaster.
>>
>>
>>
>> On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
>>  wrote:
>>> Now that JavaFX requires JDK 24 to build, we can use features from JDK
>>> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
>>> delivered in JDK 23.
>>>
>>> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
>>> proposed changes that do just that.
>>>
>>> As was pointed out in a review comment on PR 1873 [3], we should make a
>>> deliberate decision to start using them and have some guidelines around
>>> doing so.
>>>
>>> To that end, I would propose that developers can start using markdown
>>> javadoc comments in new APIs and in APIs that are modified such that
>>> markdown comments would be helpful.
>>>
>>> This is not an invitation to do wholesale changing of existing javadoc
>>> comments to markdown-style comments for docs that otherwise aren't being
>>> modified.
>>>
>>> Comments are welcome.
>>>
>>> -- Kevin
>>>
>>> [0] https://openjdk.org/jeps/467
>>> [1] https://github.com/openjdk/jfx/pull/1873
>>> [2] https://github.com/openjdk/jfx/pull/1880
>>> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kizune at openjdk.org  Fri Oct 10 20:08:38 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 10 Oct 2025 20:08:38 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v5]
In-Reply-To: 
References: 
Message-ID: 

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

Alexander Zuev 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 nine additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8368972
 - Merge pull request #22 from openjdk/master
   
   Merge
 - Cover the case when menu item has children but it does not respond to the accessibilityValue selector;
 - Caching children list;
   Use nil instead of NULL;
 - Restore CHECK_MENU_ITEM binding
 - Fixing wrong copyright year
 - Fixing the assignment;
   Fixing the top level manu titles;
 - Fixed typo
 - 8368972: Create implementation of menu bar accessibility component
   
   Create a menu bar component accessibility peer and wire it to the component

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1927/files
  - new: https://git.openjdk.org/jfx/pull/1927/files/7e83d9bd..aca3061f

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

  Stats: 691 lines in 51 files changed: 555 ins; 40 del; 96 mod
  Patch: https://git.openjdk.org/jfx/pull/1927.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1927/head:pull/1927

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

From duke at openjdk.org  Fri Oct 10 21:08:42 2025
From: duke at openjdk.org (BlueGoliath)
Date: Fri, 10 Oct 2025 21:08:42 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 5 Oct 2025 20:10:02 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove newline from imports
>  - assert row creation count as well

What needs to happen for this to get merged? Testing?

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3392307601

From angorya at openjdk.org  Fri Oct 10 21:12:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Oct 2025 21:12:47 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 5 Oct 2025 20:10:02 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove newline from imports
>  - assert row creation count as well

I don't see any obvious issues with the new code.

Performance wise, feels no different than the master branch.  Using the monkey tester with 10,000 rows and 200 columns, both feel sluggish on vertical scrolling, which disappears once a fixedCellSize is set.

modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 1767:

> 1765:     /**
> 1766:      * Calling {@code refresh()} forces the TableView control to repopulate the
> 1767:      * cells necessary to populate the visual bounds of the control.

the word 'repopulate' is used twice (here and elsewhere)

I would suggest to rephrase these comments to indicate what happens exactly, possibly borrowing text from the `VirtualFlow`:

- recreate: a layout pass should be done, and that the cell factory has changed. All cells in the viewport are recreated with the new cell factory.
- rebuild: a layout pass should be done, and cell contents have changed. All cells are removed and then added properly in the viewport

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 305:

> 303:                 return;
> 304:             }
> 305:             if (Properties.RECREATE.equals(c.getKey())) {

I just have to raise this concern.

It looks weird to me to use properties as a roundabout way to invoke a hidden method in the skin.  Node properties, a public facility, can be easily mutated by unrelated code, making it easy to break the intended functionality.

Why not make these two methods explicitly a part of the public API by replacing `requestRebuildCells` and `requestRecreateCells` with


protected VirtualContainerBase.rebuildCells()
protected VirtualContainerBase.recreateCells()


? 

(requestXXX is a misnomer - it might suggest an async nature, whereas it these are synchronous methods)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3325735209
PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2421948069
PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2422022393

From angorya at openjdk.org  Fri Oct 10 21:14:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 10 Oct 2025 21:14:30 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 9 Oct 2025 20:17:06 GMT, Andy Goryachev  wrote:

> a weird regression

any comments?

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3392319454

From kcr at openjdk.org  Fri Oct 10 22:37:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 22:37:46 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 10 Oct 2025 20:27:10 GMT, Andy Goryachev  wrote:

>> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove newline from imports
>>  - assert row creation count as well
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 305:
> 
>> 303:                 return;
>> 304:             }
>> 305:             if (Properties.RECREATE.equals(c.getKey())) {
> 
> I just have to raise this concern.
> 
> It looks weird to me to use properties as a roundabout way to invoke a hidden method in the skin.  Node properties, a public facility, can be easily mutated by unrelated code, making it easy to break the intended functionality.
> 
> Why not make these two methods explicitly a part of the public API by replacing `requestRebuildCells` and `requestRecreateCells` with
> 
> 
> protected VirtualContainerBase.rebuildCells()
> protected VirtualContainerBase.recreateCells()
> 
> 
> ? 
> 
> (requestXXX is a misnomer - it might suggest an async nature, whereas it these are synchronous methods)

Changing this is out of scope for this PR.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2422192916

From kcr at openjdk.org  Fri Oct 10 22:37:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Oct 2025 22:37:46 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 22:32:17 GMT, Kevin Rushforth  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 305:
>> 
>>> 303:                 return;
>>> 304:             }
>>> 305:             if (Properties.RECREATE.equals(c.getKey())) {
>> 
>> I just have to raise this concern.
>> 
>> It looks weird to me to use properties as a roundabout way to invoke a hidden method in the skin.  Node properties, a public facility, can be easily mutated by unrelated code, making it easy to break the intended functionality.
>> 
>> Why not make these two methods explicitly a part of the public API by replacing `requestRebuildCells` and `requestRecreateCells` with
>> 
>> 
>> protected VirtualContainerBase.rebuildCells()
>> protected VirtualContainerBase.recreateCells()
>> 
>> 
>> ? 
>> 
>> (requestXXX is a misnomer - it might suggest an async nature, whereas it these are synchronous methods)
>
> Changing this is out of scope for this PR.

Having said that, I've always disliked using user properties for this sort of thing. It feels like a bit of a hack, so it might be worth filing a follow-up to evaluate a different approach in general (not just for this one instance of the pattern). I don't see this as a high priority, though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2422200259

From nlisker at openjdk.org  Fri Oct 10 22:46:36 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 10 Oct 2025 22:46:36 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v3]
In-Reply-To: 
References: 
Message-ID: 

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

  Changed to HTML comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1873/files
  - new: https://git.openjdk.org/jfx/pull/1873/files/cc11d675..55717111

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

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

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

From nlisker at openjdk.org  Fri Oct 10 22:46:38 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 10 Oct 2025 22:46:38 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: 
References: 
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 19:35:00 GMT, Kevin Rushforth  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing @since
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 7714:
> 
>> 7712:     }
>> 7713: 
>> 7714:     public final EventHandler getOnMouseDragDone() {
> 
> We normally put the property methods that will inherit the docs below the method (or private property as the case may be) that has the javadoc comments.
> 
> I recommend to move these two methods below the `onMouseDragDoneProperty` method.

All of the properties above it have the same arrangement.

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

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

From mfox at openjdk.org  Sat Oct 11 06:52:19 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 11 Oct 2025 06:52:19 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: <3o9Fl1djD20rF5DrE4MOvVrWJKsIrW5VNM1MPVXvIX0=.3ad7ebe1-ee2a-456d-8a41-a8f6594a5175@github.com>
References: 
 <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
 
 
 <3o9Fl1djD20rF5DrE4MOvVrWJKsIrW5VNM1MPVXvIX0=.3ad7ebe1-ee2a-456d-8a41-a8f6594a5175@github.com>
Message-ID: 

On Fri, 10 Oct 2025 14:59:09 GMT, Kevin Rushforth  wrote:

>>> Could this lead to two resize commands in some cases?
>> 
>> Yes, I was trying not to be too clever with my checks. I figured if the second notification wasn't necessary it would be benign. At the very least it won't trigger invalidation of the window's width and height properties.
>> 
>> I will tighten this up since I have to tweak the code a bit anyway. I just verified that on Windows you can alter the size of a maximized window and the OS will keep it in the MAXIMIZED state (as it resizes glass calls notifyResize with WindowEvent.MAXIMIZED). This PR can kick the window out of the MAXIMIZED or MINIMIZED state incorrectly. Unfortunately it puts the window in the wrong internal state without updating the maximized or iconified properties so it's not easy to write a test to detect this.
>
> This is pending work from you, right? I'll put it back on my review queue once you make the changes you mentioned above.

I've made the changes. It should be ready for review.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2422543900

From jvos at openjdk.org  Sat Oct 11 08:55:18 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 11 Oct 2025 08:55:18 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 12:46:08 GMT, Jose Pereda  wrote:

>> tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 49:
>> 
>>> 47:             Platform.runLater(Platform::exit);
>>> 48:         });
>>> 49:         Util.sleep(10);
>> 
>> Is 10msec enough?
>
> I'm testing on an M1, but you are right, on different environments it could take longer.
> 
> I've added now an exit latch from `PlatformImplShim.test_getPlatformExitLatch()`, so we wait whatever is needed until `PlatformImpl.tkExit()` finishes, and then those 10 ms should be more than enough (but we still need to wait a couple of ms nonetheless until the JavaFX thread is fully gone).

In general, I'm not a fan of adding hard-numbered sleep times. Either the expected events are delivered, or they are not (yet). The hard sleep pattern leads to either slowdowns or to failing tests on slow environments.
Using CountdownLatches and deterministic flows is much better for testing, imho.
Since the Util.sleep is widely used in other system tests, I'm ok with using it here as well -- but I still think it is a dangerous approach.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2422628813

From jvos at openjdk.org  Sat Oct 11 09:08:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 11 Oct 2025 09:08:19 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: 

On Fri, 10 Oct 2025 12:56:02 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback from reviewer

This is a good PR that adds previously missing functionality.

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3326874870

From jvos at openjdk.org  Sat Oct 11 09:08:21 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 11 Oct 2025 09:08:21 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
Message-ID: 

On Fri, 10 Oct 2025 14:47:13 GMT, Andy Goryachev  wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process feedback from reviewer
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 66:
> 
>> 64:     void stopProcessing() {
>> 65:         for (RunLoopEntry entry : activeRunLoops) {
>> 66:             runnableQueue.add(() -> entry.active = false);
> 
> I would highly recommend declaring `RunLoopEntry.active` `volatile`.

Can you elaborate on this? What usecase do you see where 2 threads might see different values, leading to problems that could not occur if active was volatile?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2422639516

From kcr at openjdk.org  Sat Oct 11 12:09:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:09:46 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
 
 <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
 
Message-ID: 

On Sun, 5 Oct 2025 17:11:51 GMT, Marius Hanl  wrote:

>>> > I think the changes look good. I'm a bit confused in the performance table with what is meant with the `50 ms -> 0 ms` in the "after" cases though?
>>> 
>>> Every `refresh()` will trigger 2 layouts for some reason, where the second one does nothing as nothing is dirty, so basically a noop. I can have a look into that (maybe as a follow up?) but I remember that this happens sometimes in general for the `VirtualFlow` and we should check that generally at one point.
>> 
>> No need to address that in this PR,  I was just confused what the numbers meant (shouldn't the `before` column than not also have `X ms -> 0 ms`?).  So it seems like quite a good performance improvement.
>> 
>> As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/  How many cells were visible?  1000 or 100x1000?  If the latter, than 30-40 ms seems okayish.
>
>> As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/ How many cells were visible? 1000 or 100x1000? If the latter, than 30-40 ms seems okayish.
> 
> I agree. One problem here is, that all cells will be updated (via `updateItem`) of a `TableRow`, even if not visible. 
> 
> I counted all `updateItem` calls, results below.
> 
> Code from Benchmark above:
> - `TableRow` `updateItem`: 78
> - `TableCell` `updateItem`: 7800
> 
> 39 rows are displayed, and they are updated twice (first with `-1` to reset, then with the actual index). And all rows have 100 cells.
> 
> A `TableCell` `updateItem` without any code (no `setText`, no `setGraphic`) is indeed faster, around 10-20ms.
> Looking into the code, there are some unnecessary `requestLayout` calls as well.

@Maran23 Can you add the performance test program you ran to validate the performance numbers to this PR? A new directory under `tests/performance` seems a good place for it.

I'll review the CSR.

@johanvos had some comments earlier, so allow time for him to respond as well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3393245504

From mstrauss at openjdk.org  Sat Oct 11 12:10:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 11 Oct 2025 12:10:24 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 22:46:36 GMT, Nir Lisker  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:
> 
>   Changed to HTML comments

modules/javafx.graphics/src/main/java/javafx/scene/input/MouseDragEvent.java line 132:

> 130:     /**
> 131:      * This event occurs when the gesture ends. It is delivered exactly once to the source node/scene, and is always the
> 132:      * last event in the full press-drag-release process. It is delivered even when the mouse is outside the application.

1. `It is delivered exactly once to the source node/scene`: you could probably remove `/scene`, it is implied by the way events work. Maybe be a bit more precise: `It is delivered exactly once to the node on which the press-drag-release gesture was started`.
2. `outside the application` is a bit vague, as applications don't have a spatial extent. How about: `It is delivered even when the mouse was released outside of the window`.

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

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

From duke at openjdk.org  Sat Oct 11 12:20:30 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Sat, 11 Oct 2025 12:20:30 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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/33bc0e2a..7e6e9a6d

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

  Stats: 886 lines in 10 files changed: 444 ins; 427 del; 15 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  Sat Oct 11 12:20:31 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Sat, 11 Oct 2025 12:20:31 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
References: 
 <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
Message-ID: 

On Tue, 30 Sep 2025 23:31:20 GMT, Pabulaner IV  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 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

Thanks for the improvements. I should have implemented all of them, please take a look again.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3393253171

From kcr at openjdk.org  Sat Oct 11 12:29:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:29:43 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 5 Oct 2025 20:10:02 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove newline from imports
>  - assert row creation count as well

I left one comment on the docs. I'll leave it to the other reviewers to test and review the implementation changes.

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

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3327030399

From kcr at openjdk.org  Sat Oct 11 12:29:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:29:44 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>

On Fri, 10 Oct 2025 19:53:26 GMT, Andy Goryachev  wrote:

>> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove newline from imports
>>  - assert row creation count as well
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 1767:
> 
>> 1765:     /**
>> 1766:      * Calling {@code refresh()} forces the TableView control to repopulate the
>> 1767:      * cells necessary to populate the visual bounds of the control.
> 
> the word 'repopulate' is used twice (here and elsewhere)
> 
> I would suggest to rephrase these comments to indicate what happens exactly, possibly borrowing text from the `VirtualFlow`:
> 
> - recreate: a layout pass should be done, and that the cell factory has changed. All cells in the viewport are recreated with the new cell factory.
> - rebuild: a layout pass should be done, and cell contents have changed. All cells are removed and then added properly in the viewport

At a minimum, replace the first occurrence of "repopulate" with "rebuild".


     * Calling {@code refresh()} forces the TableView control to rebuild the
     * cells necessary to populate the visual bounds of the control.


I wouldn't over-specify this by saying what `VirtualFlow` will do, but if you want to add a sentence saying that this will request a layout that would be fine:


     * Calling {@code refresh()} forces the TableView control to rebuild the
     * cells necessary to populate the visual bounds of the control.
     * This will request a layout of the TableView cells.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2422774420

From kcr at openjdk.org  Sat Oct 11 12:34:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:34:18 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: 
References: 
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 
 
Message-ID: 

On Fri, 10 Oct 2025 22:42:21 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 7714:
>> 
>>> 7712:     }
>>> 7713: 
>>> 7714:     public final EventHandler getOnMouseDragDone() {
>> 
>> We normally put the property methods that will inherit the docs below the method (or private property as the case may be) that has the javadoc comments.
>> 
>> I recommend to move these two methods below the `onMouseDragDoneProperty` method.
>
> All of the properties above it have the same arrangement.

Yes, you're right.

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

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

From kcr at openjdk.org  Sat Oct 11 12:37:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:37:19 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
 
 
 <3o9Fl1djD20rF5DrE4MOvVrWJKsIrW5VNM1MPVXvIX0=.3ad7ebe1-ee2a-456d-8a41-a8f6594a5175@github.com>
 
Message-ID: 

On Sat, 11 Oct 2025 06:49:36 GMT, Martin Fox  wrote:

>> This is pending work from you, right? I'll put it back on my review queue once you make the changes you mentioned above.
>
> I've made the changes. It should be ready for review.

I completely missed that you had already done this. I'll review it then.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2422784404

From kcr at openjdk.org  Sat Oct 11 12:46:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:46:53 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1
Message-ID: 

Release notes for JavaFX 25.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

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

The original filter, with the backport IDs, is here:

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

As usual, I excluded test bugs, cleanup bugs, etc.

NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

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

Commit messages:
 - 8369610: Create release notes for JavaFX 25.0.1

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

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

From kcr at openjdk.org  Sat Oct 11 12:46:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Oct 2025 12:46:54 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Oct 2025 22:27:06 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 25.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=48166
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=48165
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

Reviewers: @arapte or @andy-goryachev-oracle

@tiainen or @abhinayagarwal : can one of you take a look as well?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/24#issuecomment-3393275988

From nlisker at openjdk.org  Sat Oct 11 13:16:37 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 11 Oct 2025 13:16:37 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v4]
In-Reply-To: 
References: 
Message-ID: 

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

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1873/files
  - new: https://git.openjdk.org/jfx/pull/1873/files/55717111..eb16e369

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

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

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

From nlisker at openjdk.org  Sat Oct 11 13:16:40 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 11 Oct 2025 13:16:40 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <6quc2oFGmI5o_rSAntC5TpIcsvuWBM2Y24wsehurdTY=.690485cf-416b-40ff-a75d-71fc20254278@github.com>

On Sat, 11 Oct 2025 12:07:49 GMT, Michael Strau?  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed to HTML comments
>
> modules/javafx.graphics/src/main/java/javafx/scene/input/MouseDragEvent.java line 132:
> 
>> 130:     /**
>> 131:      * This event occurs when the gesture ends. It is delivered exactly once to the source node/scene, and is always the
>> 132:      * last event in the full press-drag-release process. It is delivered even when the mouse is outside the application.
> 
> 1. `It is delivered exactly once to the source node/scene`: you could probably remove `/scene`, it is implied by the way events work. Maybe be a bit more precise: `It is delivered exactly once to the node on which the press-drag-release gesture was started`.
> 2. `outside the application` is a bit vague, as applications don't have a spatial extent. How about: `It is delivered even when the mouse was released outside of the window`.

1. I'm not sure why scene is implied from node considering it's not a node - the language often used is "gesture source". This is also why I don't understand why remove that term and replace it with its meaning.
2. Changed.

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

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

From nlisker at openjdk.org  Sat Oct 11 13:57:19 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 11 Oct 2025 13:57:19 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v5]
In-Reply-To: 
References: 
Message-ID: 

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

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1873/files
  - new: https://git.openjdk.org/jfx/pull/1873/files/eb16e369..54daba50

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

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

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

From nlisker at openjdk.org  Sat Oct 11 13:57:20 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 11 Oct 2025 13:57:20 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v3]
In-Reply-To: 
References: 
 
 
 <6quc2oFGmI5o_rSAntC5TpIcsvuWBM2Y24wsehurdTY=.690485cf-416b-40ff-a75d-71fc20254278@github.com>
 
Message-ID: 

On Sat, 11 Oct 2025 13:48:41 GMT, Michael Strau?  wrote:

>> 1. I'm not sure why scene is implied from node considering it's not a node - the language often used is "gesture source". This is also why I don't understand why remove that term and replace it with its meaning.
>> 2. Changed.
>
> Why do you use the term "node" then, if it shouldn't mean `Node`?
> 
> `Scene` is always implied, as you can't receive input events for event targets that are not part of a scene graph.
> 
> Maybe use "gesture source", if that's what is often used here. The wording "node/scene" throws me off: is it one, or the other, or both? It's unnecessarily vague.

Changed to "gesture source".

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

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

From mstrauss at openjdk.org  Sat Oct 11 13:51:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 11 Oct 2025 13:51:22 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v3]
In-Reply-To: <6quc2oFGmI5o_rSAntC5TpIcsvuWBM2Y24wsehurdTY=.690485cf-416b-40ff-a75d-71fc20254278@github.com>
References: 
 
 
 <6quc2oFGmI5o_rSAntC5TpIcsvuWBM2Y24wsehurdTY=.690485cf-416b-40ff-a75d-71fc20254278@github.com>
Message-ID: 

On Sat, 11 Oct 2025 13:12:47 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/input/MouseDragEvent.java line 132:
>> 
>>> 130:     /**
>>> 131:      * This event occurs when the gesture ends. It is delivered exactly once to the source node/scene, and is always the
>>> 132:      * last event in the full press-drag-release process. It is delivered even when the mouse is outside the application.
>> 
>> 1. `It is delivered exactly once to the source node/scene`: you could probably remove `/scene`, it is implied by the way events work. Maybe be a bit more precise: `It is delivered exactly once to the node on which the press-drag-release gesture was started`.
>> 2. `outside the application` is a bit vague, as applications don't have a spatial extent. How about: `It is delivered even when the mouse was released outside of the window`.
>
> 1. I'm not sure why scene is implied from node considering it's not a node - the language often used is "gesture source". This is also why I don't understand why remove that term and replace it with its meaning.
> 2. Changed.

Why do you use the term "node" then, if it shouldn't mean `Node`?

`Scene` is always implied, as you can't receive input events for event targets that are not part of a scene graph.

Maybe use "gesture source", if that's what is often used here. The wording "node/scene" throws me off: is it one, or the other, or both? It's unnecessarily vague.

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

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

From mstrauss at openjdk.org  Sat Oct 11 17:16:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 11 Oct 2025 17:16:19 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v5]
In-Reply-To: 
References: 
 
Message-ID: <7uXnKIhkx6hzQtYcgmgnVXdLsGK3IKSwJdjKQPP5afo=.915369ab-291e-4cd0-9615-cea065128203@github.com>

On Sat, 11 Oct 2025 13:57:19 GMT, Nir Lisker  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:
> 
>   Review comments

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3327482438

From mhanl at openjdk.org  Sun Oct 12 14:52:41 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 12 Oct 2025 14:52:41 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
 
 <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
 
Message-ID: 

On Sun, 5 Oct 2025 17:11:51 GMT, Marius Hanl  wrote:

>>> > I think the changes look good. I'm a bit confused in the performance table with what is meant with the `50 ms -> 0 ms` in the "after" cases though?
>>> 
>>> Every `refresh()` will trigger 2 layouts for some reason, where the second one does nothing as nothing is dirty, so basically a noop. I can have a look into that (maybe as a follow up?) but I remember that this happens sometimes in general for the `VirtualFlow` and we should check that generally at one point.
>> 
>> No need to address that in this PR,  I was just confused what the numbers meant (shouldn't the `before` column than not also have `X ms -> 0 ms`?).  So it seems like quite a good performance improvement.
>> 
>> As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/  How many cells were visible?  1000 or 100x1000?  If the latter, than 30-40 ms seems okayish.
>
>> As a side note, even 30-40 ms seems incredibly slow, that's bound to create noticeable input lag or frame skips :/ How many cells were visible? 1000 or 100x1000? If the latter, than 30-40 ms seems okayish.
> 
> I agree. One problem here is, that all cells will be updated (via `updateItem`) of a `TableRow`, even if not visible. 
> 
> I counted all `updateItem` calls, results below.
> 
> Code from Benchmark above:
> - `TableRow` `updateItem`: 78
> - `TableCell` `updateItem`: 7800
> 
> 39 rows are displayed, and they are updated twice (first with `-1` to reset, then with the actual index). And all rows have 100 cells.
> 
> A `TableCell` `updateItem` without any code (no `setText`, no `setGraphic`) is indeed faster, around 10-20ms.
> Looking into the code, there are some unnecessary `requestLayout` calls as well.

> @Maran23 Can you add the performance test program you ran to validate the performance numbers to this PR? A new directory under `tests/performance` seems a good place for it.

Sure. I don't know how easy it is, but it might be worth to consider using `JMH` in the future. No idea if this is easy to wire up with JavaFX though.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3394597024

From mhanl at openjdk.org  Sun Oct 12 14:52:43 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 12 Oct 2025 14:52:43 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 22:35:07 GMT, Kevin Rushforth  wrote:

>> Changing this is out of scope for this PR.
>
> Having said that, I've always disliked using user properties for this sort of thing. It feels like a bit of a hack, so it might be worth filing a follow-up to evaluate a different approach in general (not just for this one instance of the pattern). I don't see this as a high priority, though.

Adding to what @kevinrushforth said, this is used everywhere. All layout constraints are implemented by using `Properties`. Changing anything there can break the layout.

If we just talking about the properties calling a method in the skin, I dislike the current way as well, but have no other idea really. Maybe a good topic for the mailing list then.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2424249176

From jvos at openjdk.org  Sun Oct 12 17:46:42 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Oct 2025 17:46:42 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
References: 
 
 
 
 <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
Message-ID: 

On Sat, 4 Oct 2025 04:28:19 GMT, John Hendrikx  wrote:

> Every `refresh()` will trigger 2 layouts for some reason, where the second one does nothing as nothing is dirty, so basically a noop. I can have a look into that (maybe as a follow up?) but I remember that this happens sometimes in general for the `VirtualFlow` and we should check that generally at one point.

This is something that worries me. One of the main issues I see with e.g. VirtualFlow, is that some methods can be invoked both during a rendering pulse as well as (indirectly) via explicit invocations, most often by code invoked with Platform.runLater().
Depending on whether code is called during a pulse or not, the behavior can be very different. A major problematic consequence of a method that used to be called outside the pulse, and that is now for some reason (e.g. due to concurrency, as it depends whether the Runnable submitted to Platform.runLater() is executed before or after the pulse) called during a pulse, is that this can lead to flickering. If `requestNextPulse` is called during the layout phase, it is very well possible that a "wrong" layout is rendered briefly before the correct layout is shown.

I am not saying that this PR makes the situation worse or better, but I think there is a reasonable chance that some applications will behave differently (and show flickering). Having said that, I don't think that this PR can be blamed in case there is a different behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3395041542

From jdv at openjdk.org  Mon Oct 13 04:38:25 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 13 Oct 2025 04:38:25 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 15:55:07 GMT, John Hendrikx  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 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 nine additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into feature/image-constructor
>  - Clarify docs
>  - Fix formatting
>  - Clarify documentation with regards to stream closing
>  - Fix typo
>  - Add links to progress property in javadoc
>  - Remove wrapping
>  - Add since tags
>  - 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 max exceed 2 GB
>    - Improved documentation of Image regarding background loading

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1875#pullrequestreview-3329944744

From mfox at openjdk.org  Mon Oct 13 07:20:28 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 13 Oct 2025 07:20:28 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v3]
In-Reply-To: 
References: 
 <_pHCMyTng8UAfQ3tA7N_g8T-o_NbLHMW7kABYVgpyOk=.f39ff954-6531-47e3-86a9-75abbc8ba212@github.com>
 
Message-ID: 

On Thu, 9 Oct 2025 17:16:22 GMT, Pabulaner IV  wrote:

> Thanks for the detailed feedback, much appreciated. So as far as I understood Your feedback it means that the PR from Your side would be good to go, but maybe in the future some minor bug / issue fixes would be nice to have?

I need to do a more detailed review of the platform code but for now I haven't seen any problems with it. To review the changes to, say, _setMenubar I needed to first understand when it is called and that's what I was focusing on. 

There is an unexpected testing burden. When a popup appears in an FXPanel (as a tooltip, combo box, or menu) the core code will try to set the system menu bar for no good reason and it's up to the platform code to make sure it doesn't succeed. I'm not sure it warrants a system test but some testing needs to be done for these cases. This core behavior really should be addressed in a follow up issue but that's not something I can do until November.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3396166710

From jbhaskar at openjdk.org  Mon Oct 13 08:59:24 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 13 Oct 2025 08:59:24 GMT
Subject: Integrated: 8367578: Additional WebKit 622.1 fixes from WebKitGTK
 2.48.7
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Oct 2025 03:21:20 GMT, Jay Bhaskar  wrote:

> WebKitGTK 2.48.6 and 2.48.7 are bug-fix releases that improve stability, fix crashes, memory leaks, emoji rendering, WebP animation stuttering, and CSS animation issues, while also adding better font support and preventing unnecessary memory monitoring.

This pull request has now been integrated.

Changeset: adb6c11e
Author:    Jay Bhaskar 
URL:       https://git.openjdk.org/jfx/commit/adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e
Stats:     233 lines in 41 files changed: 141 ins; 36 del; 56 mod

8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7

Reviewed-by: kcr, sykora

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

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

From kcr at openjdk.org  Mon Oct 13 12:03:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 12:03:52 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 10 Oct 2025 15:00:54 GMT, John Hendrikx  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify documentation with regards to stream closing
>
> Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.

@hjohn The last piece is the CSR. I'll review it once it is ready.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3397233327

From kcr at openjdk.org  Mon Oct 13 12:18:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 12:18:34 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 13:57:19 GMT, Nir Lisker  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:
> 
>   Review comments

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3331371973

From kcr at openjdk.org  Mon Oct 13 12:18:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 12:18:35 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: 
References: 
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 
 
 
 
Message-ID: <0bdTJC8XxgKPBINgHqTuT6drbB_jLWc8pNe8I3jRJ4Y=.109b856c-9405-4054-9faf-3ff6db70b2a2@github.com>

On Wed, 1 Oct 2025 14:46:08 GMT, Nir Lisker  wrote:

>>> I have a future docs change in the works around mouse events that clears up a lot of things.
>> 
>> Is it going to be a separate PR or a part of this one?
>
>> > I have a future docs change in the works around mouse events that clears up a lot of things.
>> 
>> Is it going to be a separate PR or a part of this one?
> 
> Separate. It will encompass mouse events and drag events, though I hit an obstacle with testing touch events.

@nlisker I'll review the CSR after you've updated the spec to match the latest doc changes.

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

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

From mhanl at openjdk.org  Mon Oct 13 12:27:19 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Oct 2025 12:27:19 GMT
Subject: RFR: 8089514: [TableView, TreeView, ListView,
 TreeTableView] Clicking outside of the edited cell, node,
 or entry should commit the value
Message-ID: 

This is an initial poc for the long standing issue of allowing to commit a cell value when the focus is lost. This also contains [JDK-8089311](https://bugs.openjdk.org/browse/JDK-8089311) (for better understanding the usecase with `TextFiield` cells, but we may split this later on).

API
-
- Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the focus is lost. The default behavior is cancelling the edit, but developers can now override the behavior and allow a `commitEdit` instead
- Every `MOUSE_PRESSED` shifts the focus to the cell container, which is undesired in case of editing the cell. So this event is now consumed.
- All `TextField` cells now commit their value (instead of cancel) on focus loss

Considerations
-
- I tried to make the API minimal, and without breaking changes (other than the `TextField` cells committing their values, but we may split this up)
- The Cell Container focus behavior is, well, weird right now. That is why consuming the event is needed to better support this PR. One thing we may can consider is using the `focusWithin` property instead for all 4 Cell Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` event. If we decide so, this is needs to be done before merging this PR.
- Clicking the `ScrollBar` now commits/cancels the edit. I checked other applications and this is very common. But something I need to note here. This probably can be fixed in the same way mentioned above (`focusWithin`)

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

Commit messages:
 - focus edit

Changes: https://git.openjdk.org/jfx/pull/1935/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8089514
  Stats: 488 lines in 27 files changed: 382 ins; 23 del; 83 mod
  Patch: https://git.openjdk.org/jfx/pull/1935.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1935/head:pull/1935

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

From mhanl at openjdk.org  Mon Oct 13 12:28:42 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Oct 2025 12:28:42 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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).
> 
> ----
> 
> Benchmarks
> -
> 
> Setup:
> - `TableView`
> - `100 TableColumns`
> - `1000 Items`
> 
> Calling `refresh()` with a `Button` press.
> 
> | WHAT | BEFORE | AFTER |
> | - | - | - |
> | Init | 0ms |0 ms |
> | Init | 0ms | 0 ms |
> | Init | 251 ms | 246 ms |
> | Init | 47 ms | 50 ms |
> | Init | 24 ms | 5 ms |
> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
> 
> 
> 
> 

> Benchmark code
> 
> 
> import javafx.application.Application;
> import javafx.beans.property.SimpleStringProperty;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.control.IndexedCell;
> import javafx.scene.control.TableColumn;
> import javafx.scene.control.TableRow;
> import javafx.scene.control.TableView;
> import javafx.scene.control.skin.TableViewSkin;
> import javafx.scene.control.skin.VirtualFlow;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.HBox;
> import javafx.stage.Stage;
> 
> public class FXBug {
> 
>     public static void main(String[] args) {
>         Application.launch(FxApp.class, args);
>     }
> 
>     public static class FxApp extends Application {
> 
>         @Override
>         public void start(Stage primaryStage) {
>             TableV...

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

  Improve javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1830/files
  - new: https://git.openjdk.org/jfx/pull/1830/files/1376cb3b..0575d6fb

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

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

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

From mhanl at openjdk.org  Mon Oct 13 12:28:45 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Oct 2025 12:28:45 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
Message-ID: 

On Sat, 11 Oct 2025 12:22:53 GMT, Kevin Rushforth  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java line 1767:
>> 
>>> 1765:     /**
>>> 1766:      * Calling {@code refresh()} forces the TableView control to repopulate the
>>> 1767:      * cells necessary to populate the visual bounds of the control.
>> 
>> the word 'repopulate' is used twice (here and elsewhere)
>> 
>> I would suggest to rephrase these comments to indicate what happens exactly, possibly borrowing text from the `VirtualFlow`:
>> 
>> - recreate: a layout pass should be done, and that the cell factory has changed. All cells in the viewport are recreated with the new cell factory.
>> - rebuild: a layout pass should be done, and cell contents have changed. All cells are removed and then added properly in the viewport
>
> At a minimum, replace the first occurrence of "repopulate" with "rebuild".
> 
> 
>      * Calling {@code refresh()} forces the TableView control to rebuild the
>      * cells necessary to populate the visual bounds of the control.
> 
> 
> I wouldn't over-specify this by saying what `VirtualFlow` will do, but if you want to add a sentence saying that this will request a layout that would be fine:
> 
> 
>      * Calling {@code refresh()} forces the TableView control to rebuild the
>      * cells necessary to populate the visual bounds of the control.
>      * This will request a layout of the TableView cells.

Changed to rebuild. I did not add the request layout line, in case we may want to change this later. Since as @hjohn and @johanvos mentioned, it is rather weird right now.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2426194114

From mhanl at openjdk.org  Mon Oct 13 12:30:36 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Oct 2025 12:30:36 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v2]
In-Reply-To: 
References: 
 
 
 
 <8vXgPH8FnP6qaO-lhYP-Hp-stplAc2mLCzclF_nc8Bg=.f9d1cef4-eb38-45e8-ad18-165b73a138de@github.com>
 
Message-ID: 

On Sun, 12 Oct 2025 17:43:32 GMT, Johan Vos  wrote:

> This is something that worries me. One of the main issues I see with e.g. VirtualFlow, is that some methods can be invoked both during a rendering pulse as well as (indirectly) via explicit invocations, most often by code invoked with Platform.runLater(). Depending on whether code is called during a pulse or not, the behavior can be very different. A major problematic consequence of a method that used to be called outside the pulse, and that is now for some reason (e.g. due to concurrency, as it depends whether the Runnable submitted to Platform.runLater() is executed before or after the pulse) called during a pulse, is that this can lead to flickering. If `requestNextPulse` is called during the layout phase, it is very well possible that a "wrong" layout is rendered briefly before the correct layout is shown.

I'm also not happy with the current situation. There are also some cases where cells request a layout while they are layouted. There is quite some room to optimize several scenarios here.
I would like to check this out and optimize at one point, but really afraid that there might be regressions. So this will probably take a while, but I have a far better understanding of the `VirtualFlow` and surrounding classes than e.g. a year ago + we have far more tests as well!

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3397320838

From nlisker at openjdk.org  Mon Oct 13 12:31:10 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 13 Oct 2025 12:31:10 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v2]
In-Reply-To: 
References: 
 <_7N7pLwxaBglA3IINPY_YjaszZ9DcC-ocAqR0en8juA=.a262526d-967a-42c3-a768-4c74f15056ce@github.com>
 
 
 
 
Message-ID: 

On Wed, 1 Oct 2025 14:46:08 GMT, Nir Lisker  wrote:

>>> I have a future docs change in the works around mouse events that clears up a lot of things.
>> 
>> Is it going to be a separate PR or a part of this one?
>
>> > I have a future docs change in the works around mouse events that clears up a lot of things.
>> 
>> Is it going to be a separate PR or a part of this one?
> 
> Separate. It will encompass mouse events and drag events, though I hit an obstacle with testing touch events.

> @nlisker I'll review the CSR after you've updated the spec to match the latest doc changes.

Updated.

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

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

From mariushanl at web.de  Mon Oct 13 12:53:54 2025
From: mariushanl at web.de (mariushanl at web.de)
Date: Mon, 13 Oct 2025 12:53:54 +0000
Subject: Allowing a cell to commit the value on focus loss
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From mhanl at openjdk.org  Mon Oct 13 12:59:08 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 13 Oct 2025 12:59:08 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: 
References: 
 
Message-ID: <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>

On Mon, 13 Oct 2025 12:28:42 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc

There seems to be an intermediate test failure, maybe a race condition unrelated to this change:


TaskEventTest > cancelledCalledAfterHandler() FAILED
    org.opentest4j.AssertionFailedError: expected:  but was: 
        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.AssertTrue.failNotTrue(AssertTrue.java:63)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:183)
        at app//test.javafx.concurrent.TaskEventTest.cancelledCalledAfterHandler(TaskEventTest.java:410)

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3397422894

From duke at openjdk.org  Mon Oct 13 13:00:02 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Mon, 13 Oct 2025 13:00:02 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Oct 2025 22:27:06 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 25.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=48166
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=48165
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

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

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

PR Review: https://git.openjdk.org/jfx25u/pull/24#pullrequestreview-3331532198

From kcr at openjdk.org  Mon Oct 13 13:04:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 13:04:23 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
References: 
 
 <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
Message-ID: <3AEFvUGIvraWk8PxcEm4Jq5XvmMyuqhvSnLYdnp06Yk=.1310f768-7804-448d-b9de-35c1ccd89d0b@github.com>

On Mon, 13 Oct 2025 12:55:58 GMT, Marius Hanl  wrote:

> There seems to be an intermediate test failure, maybe a race condition unrelated to this change:

Yes, it is already filed and tracked by [JDK-8357459](https://bugs.openjdk.org/browse/JDK-8357459).

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3397443949

From sykora at openjdk.org  Mon Oct 13 13:29:49 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 13 Oct 2025 13:29:49 GMT
Subject: RFR: 8360586: JavaFX build uses deprecated features that will be
 removed in gradle 9 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 26 Sep 2025 10:29:44 GMT, Ambarish Rapte  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

I verified that indeed only Gradle 10.0 deprecation warnings are present.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1918#pullrequestreview-3331639446

From jhendrikx at openjdk.org  Mon Oct 13 14:06:08 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 13 Oct 2025 14:06:08 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 10 Oct 2025 15:00:54 GMT, John Hendrikx  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify documentation with regards to stream closing
>
> Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.

> @hjohn The last piece is the CSR. I'll review it once it is ready.

@kevinrushforth Sorry for the delay, I created the CSR now and moved it to proposed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3397673223

From john.hendrikx at gmail.com  Mon Oct 13 14:17:39 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 13 Oct 2025 16:17:39 +0200
Subject: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
Message-ID: <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>

Hi Marius,

This may be unrelated, but it may be problematic to rely on committing
values using focus lost:

I've built a lot of code that relies on focus lost to "commit" values to
some underlying model.? However, I noticed that a focus lost handler for
committing values is insufficient when an action is triggered that
doesn't trigger a loss of focus.?? For example, if I have a field "email
address" and a Button "Send Email", and I have a focus lost handler to
commit the email address textfield to an underlying model, then pressing
the Button will not trigger that handler and the underlying model may
not have been updated with the latest edits.

Solutions to trigger the correct action are all a bit tricky or annoying:

- Query all fields for their current contents as focus lost is not
entirely reliable for this purpose
- Have fields update models immediately (which would be on every key
press...) -- this is not very efficient, and can get in the way of
validation / model restrictions
- Have controls listen to a "COMMIT" event (this is fired at the current
focus owner by the Button).? This event may be veto'd if committing the
value resulted in a validation error, in which case the button press is
cancelled

I don't like any of these, but using the last option at the moment
because I like constant updates and having to requery UI components even
less...

--John


I noticed however that if you edit some field (it doesn't have to be in
a table view, just a regular field), and have a focus lost handler that
commits the value, that this focus lost handler is insufficient...

On 13/10/2025 14:53, mariushanl at web.de wrote:
> All,
> ?
> I created an initial poc 1* to support developers to commit the cell
> value when the focus is lost 2* (including 3*).
> More specifically, this gives the maximum flexibility to choose what
> should happen when the focus is lost or the editing index changed
> (which may happen when clicking into another cell while editing).
> All information mentioned here are also in the description of the PR.
> ?
> *API*
> *?*
> - Instead of calling `/cancelEdit/`, every cell now calls `/stopEdit/`
> when the focus is lost or the editing index changed. The default
> behavior is cancelling the edit, but developers can now override the
> behavior and allow a `/commitEdit/` instead
> - There are multiple 'events' that can lead to a editing change. Every
> change will now call `/stopEdit/`.
> It is therefore the responsibility of the developer to decide, when it
> makes sense to actually commit the value instead of cancelling it.
> This decision was made as the behavior is manipulating the editing
> index, but you as a developer can as well. We do not really know what
> intention led to e.g. a change of the editing index.
> - Every `/MOUSE_PRESSED/` shifts the focus to the cell container,
> which is undesired in case of editing the cell. So this event is now
> consumed.
> - All `/TextField/` cells now commit their value (instead of cancel)
> on focus loss
> - `/TextField/` Escape handling was badly implemented (it was never
> really called, as the cell container handled Escape before)
> ?
> *Considerations*
>
> - I tried to make the API minimal, and without breaking changes (other
> than the `/TextField/` cells committing their values, but we may split
> this up)
> - The Cell Container focus behavior is, well, weird right now. That is
> why consuming the event is needed to better support this PR. One thing
> we may can consider is using the `/focusWithin/` property instead for
> all 4 Cell Containers and not calling `/requestFocus/` for nearly
> every `/MOUSE_PRESSED/` event. If we decide so, this is needs to be
> done before merging this PR.
> - Clicking the `/ScrollBar/` now commits/cancels the edit. I checked
> other applications and this is very common. But something I need to
> note here. This probably can be fixed in the same way mentioned above
> (`/focusWithin/`)
> - It might be hard for a developer to exactly know the cause why
> `/stopEdit/` is called. This does not seem like a problem, as e.g. for
> a `/TextField/`, you normally register listeners for e.g. pressing the
> Escape key on it, so you keep full control.
> ?
> *Another Approach*
>
> - Another Approach I tested could be to request the focus to a cell
> when clicked/edited, to ensure that the focus listener is ALWAYS
> called before another cell will reach the editing state. Again, we
> probably need to change the focus handling to e.g. use the
> `/focusWithin/` property. With this approach, we can only call
> `/stopEdit` /when the focus changed (since it is now called always),
> but not when the editing index changed.
> ?
> 1* - https://github.com/openjdk/jfx/pull/1935
> 2* -?https://bugs.openjdk.org/browse/JDK-8089514
> 3* -?https://bugs.openjdk.org/browse/JDK-8089311
> ?
> -- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Mon Oct 13 15:18:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 15:18:04 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 14:03:15 GMT, John Hendrikx  wrote:

> > @hjohn The last piece is the CSR. I'll review it once it is ready.
> 
> @kevinrushforth Sorry for the delay, I created the CSR now and moved it to proposed.

No worries. I just know how easy it is to miss notifications and wanted to make sure you were aware.

I reviewed the CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3397941971

From angorya at openjdk.org  Mon Oct 13 15:52:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 15:52:19 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
Message-ID: 

On Mon, 13 Oct 2025 12:24:06 GMT, Marius Hanl  wrote:

>> At a minimum, replace the first occurrence of "repopulate" with "rebuild".
>> 
>> 
>>      * Calling {@code refresh()} forces the TableView control to rebuild the
>>      * cells necessary to populate the visual bounds of the control.
>> 
>> 
>> I wouldn't over-specify this by saying what `VirtualFlow` will do, but if you want to add a sentence saying that this will request a layout that would be fine:
>> 
>> 
>>      * Calling {@code refresh()} forces the TableView control to rebuild the
>>      * cells necessary to populate the visual bounds of the control.
>>      * This will request a layout of the TableView cells.
>
> Changed to rebuild. I did not add the request layout line, in case we may want to change this later. Since as @hjohn and @johanvos mentioned, it is rather weird right now.

Thank you, though I would insist on actually explaining what "rebuild" means, as it is not clear from the context.

`VirtualFlow` offers more detailed explanation, so perhaps we should borrow that.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2426720297

From angorya at openjdk.org  Mon Oct 13 15:55:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 15:55:12 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 13:57:19 GMT, Nir Lisker  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:
> 
>   Review comments

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3332166339

From kcr at openjdk.org  Mon Oct 13 15:56:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 15:56:40 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
Message-ID: 

On Mon, 13 Oct 2025 15:49:11 GMT, Andy Goryachev  wrote:

>> Changed to rebuild. I did not add the request layout line, in case we may want to change this later. Since as @hjohn and @johanvos mentioned, it is rather weird right now.
>
> Thank you, though I would insist on actually explaining what "rebuild" means, as it is not clear from the context.
> 
> `VirtualFlow` offers more detailed explanation, so perhaps we should borrow that.

Or maybe link to `VirtualFlow`? I'm not sure the details are important enough to repeat.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2426729770

From jbhaskar at openjdk.org  Mon Oct 13 16:00:34 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 13 Oct 2025 16:00:34 GMT
Subject: [jfx25u] RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK
 2.48.7
Message-ID: 

A clean backport for jfx25u-cpu-open. The fix is a cherry pick of webkit gtk 2.48.6, 2.48.7 and all tests are ok.

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

Commit messages:
 - Backport adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e

Changes: https://git.openjdk.org/jfx25u/pull/25/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=25&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367578
  Stats: 233 lines in 41 files changed: 141 ins; 36 del; 56 mod
  Patch: https://git.openjdk.org/jfx25u/pull/25.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/25/head:pull/25

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

From angorya at openjdk.org  Mon Oct 13 16:15:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 16:15:42 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
Message-ID: 

On Sat, 11 Oct 2025 09:05:45 GMT, Johan Vos  wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 66:
>> 
>>> 64:     void stopProcessing() {
>>> 65:         for (RunLoopEntry entry : activeRunLoops) {
>>> 66:             runnableQueue.add(() -> entry.active = false);
>> 
>> I would highly recommend declaring `RunLoopEntry.active` `volatile`.
>
> Can you elaborate on this? What usecase do you see where 2 threads might see different values, leading to problems that could not occur if active was volatile?

generally speaking, when two threads modify a single boolean variable, there might be scenarios, depending on the exact hardware, when the other thread does not see the modified value right away.

some of the comments in 

https://stackoverflow.com/questions/65037547/the-volatile-keyword-and-cpu-cache-coherence-protocol
https://stackoverflow.com/questions/106591/what-is-the-volatile-keyword-useful-for

might explain it better.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426770444

From angorya at openjdk.org  Mon Oct 13 16:15:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 16:15:43 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
 
Message-ID: 

On Sat, 11 Oct 2025 08:52:12 GMT, Johan Vos  wrote:

>> I'm testing on an M1, but you are right, on different environments it could take longer.
>> 
>> I've added now an exit latch from `PlatformImplShim.test_getPlatformExitLatch()`, so we wait whatever is needed until `PlatformImpl.tkExit()` finishes, and then those 10 ms should be more than enough (but we still need to wait a couple of ms nonetheless until the JavaFX thread is fully gone).
>
> In general, I'm not a fan of adding hard-numbered sleep times. Either the expected events are delivered, or they are not (yet). The hard sleep pattern leads to either slowdowns or to failing tests on slow environments.
> Using CountdownLatches and deterministic flows is much better for testing, imho.
> Since the Util.sleep is widely used in other system tests, I'm ok with using it here as well -- but I still think it is a dangerous approach.

I agree with @johanvos , it's always better to wait for the lock (with a timeout)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426775608

From angorya at openjdk.org  Mon Oct 13 16:20:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 16:20:09 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 15:53:42 GMT, Kevin Rushforth  wrote:

>> Thank you, though I would insist on actually explaining what "rebuild" means, as it is not clear from the context.
>> 
>> `VirtualFlow` offers more detailed explanation, so perhaps we should borrow that.
>
> Or maybe link to `VirtualFlow`? I'm not sure the details are important enough to repeat.

I would rather explain it at the top level, since it is the class the app devs use, instead of referring to some part of the skin in another package.

And what if the control uses a custom skin that is not based on the `VirtualFlow`?

In fact, the public method in this Control is the normative one, so it must define the expected behavior for all the implementors to follow.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2426785736

From angorya at openjdk.org  Mon Oct 13 16:24:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 16:24:15 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Fri, 10 Oct 2025 22:27:06 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 25.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=48166
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=48165
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

the list matches the query (sans security bugs)

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx25u/pull/24#pullrequestreview-3332261705

From kcr at openjdk.org  Mon Oct 13 16:33:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 16:33:35 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
Message-ID: <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>

On Mon, 13 Oct 2025 16:17:15 GMT, Andy Goryachev  wrote:

> In fact, the public method in this Control is the normative one, so it must define the expected behavior for all the implementors to follow.

You're absolutely right.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2426812010

From kcr at openjdk.org  Mon Oct 13 16:38:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 16:38:49 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
Message-ID: 

On Mon, 13 Oct 2025 16:10:39 GMT, Andy Goryachev  wrote:

>> Can you elaborate on this? What usecase do you see where 2 threads might see different values, leading to problems that could not occur if active was volatile?
>
> generally speaking, when two threads modify a single boolean variable, there might be scenarios, depending on the exact hardware, when the other thread does not see the modified value right away.
> 
> some of the comments in 
> 
> https://stackoverflow.com/questions/65037547/the-volatile-keyword-and-cpu-cache-coherence-protocol
> https://stackoverflow.com/questions/106591/what-is-the-volatile-keyword-useful-for
> 
> might explain it better.

Can this variable be accessed by two threads where one of them doesn't synchronize some other way? If so, then Andy has a point.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426816937

From kcr at openjdk.org  Mon Oct 13 16:38:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 16:38:50 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 16:12:41 GMT, Andy Goryachev  wrote:

>> In general, I'm not a fan of adding hard-numbered sleep times. Either the expected events are delivered, or they are not (yet). The hard sleep pattern leads to either slowdowns or to failing tests on slow environments.
>> Using CountdownLatches and deterministic flows is much better for testing, imho.
>> Since the Util.sleep is widely used in other system tests, I'm ok with using it here as well -- but I still think it is a dangerous approach.
>
> I agree with @johanvos , it's always better to wait for the lock (with a timeout)

Better, sure, but it isn't always possible in practice. There are times where a delay is still needed.

This test now waits for the lock on the condition that will lead to the thread shutting down. Good. It's still necessary to sleep for a small time to be sure that it has.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426823217

From jbhaskar at openjdk.org  Mon Oct 13 16:39:43 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 13 Oct 2025 16:39:43 GMT
Subject: [jfx25u] Integrated: 8367578: Additional WebKit 622.1 fixes from
 WebKitGTK 2.48.7
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 15:55:27 GMT, Jay Bhaskar  wrote:

> A clean backport for jfx25u-cpu-open. The fix is a cherry pick of webkit gtk 2.48.6, 2.48.7 and all tests are ok.

This pull request has now been integrated.

Changeset: 46039b8c
Author:    Jay Bhaskar 
URL:       https://git.openjdk.org/jfx25u/commit/46039b8c8b67cb677c33f495e04a9d655a31434d
Stats:     233 lines in 41 files changed: 141 ins; 36 del; 56 mod

8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7

Backport-of: adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e

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

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

From jvos at openjdk.org  Mon Oct 13 16:54:50 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Oct 2025 16:54:50 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 16:32:48 GMT, Kevin Rushforth  wrote:

>> generally speaking, when two threads modify a single boolean variable, there might be scenarios, depending on the exact hardware, when the other thread does not see the modified value right away.
>> 
>> some of the comments in 
>> 
>> https://stackoverflow.com/questions/65037547/the-volatile-keyword-and-cpu-cache-coherence-protocol
>> https://stackoverflow.com/questions/106591/what-is-the-volatile-keyword-useful-for
>> 
>> might explain it better.
>
> Can this variable be accessed by two threads where one of them doesn't synchronize some other way? If so, then Andy has a point.

I'm aware of the purpose of volatile :)
However, I'm also aware of the cost of volatile, hence I prefer not to do it unless I know there is a possible scenario where it is needed.
That is why I'm asking the same question as the one asked by Kevin.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426851714

From orion at nwra.com  Mon Oct 13 17:00:34 2025
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 13 Oct 2025 11:00:34 -0600
Subject: Trouble compiling openjfx webkit on Fedora Linux
Message-ID: 

I'm working on trying to re-enable building the openjfx webkit in the Fedora
Linux package and running into the following error:

[ 42%] Building CXX object
Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
cd
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/Source/WebCore
&& /usr/bin/g++ -DBUILDING_JAVA__=1 -DBUILDING_WEBKIT=1
-DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -DDATA_DIR=\"share\"
-DHAVE_CONFIG_H=1 -DIMAGEIO=1 -DMAX_XML_TREE_DEPTH=2000 -DPAS_BMALLOC=1
-DSTATICALLY_LINKED_WITH_JavaScriptCore -DSTATICALLY_LINKED_WITH_PAL
-DSTATICALLY_LINKED_WITH_WTF -DUSE_SYSTEM_MALLOC
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/linux
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/network
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/network/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jni
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebKitLegacy
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/../generated-src/headers
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection/Interfaces
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/InternalAPI
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/Implementation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/airplay
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applicationmanifest
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/async-clipboard
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/audiosession
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/badge
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/beacon
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cache
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/compression
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/contact-picker
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cookie-consent
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cookie-store
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/filesystemaccess
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/highlight
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/identity
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasession
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/model-element
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/model-element/dummy
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/notifications
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/permissions
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/pictureinpicture
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/plugins
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/push-api
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/remoteplayback
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/reporting
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/screen-wake-lock
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/speech
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/storage
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/streams
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/web-locks
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/cbor
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webcodecs
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webdriver
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webtransport
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webxr
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/accessibility
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/animation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings/js
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/c
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jsc
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/contentextensions
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/algorithms
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/keys
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/parameters
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/calc
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/color
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/parser
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/query
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/color
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/numeric
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/transform
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/cssjit
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/dom
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/dom/messageports
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/domjit
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/editing
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/fileapi
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/history
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/canvas
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/forms
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/parser
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/shadow
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/track
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block/tablewrapper
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/flex
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/floats
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/display
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/invalidation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/ruby
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/text
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration/flex
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration/inline
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/table
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/appcache
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/archive
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/cache
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/icon
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/mathml
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/csp
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/scrolling
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/text-extraction
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/animation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/audio
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/calc
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/gamepad
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm/filters
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/software
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/controls
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opentype
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediarecorder
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mock
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/sql
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/text
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/xr
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/plugins
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/line
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/style
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/svg
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/legacy
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/updating
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/replay
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/storage
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/style
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/animation
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/graphics
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/filters
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/properties
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/websockets
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/background-fetch
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/context
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/server
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/shared
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/shared/context
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/worklets
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/xml
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/xml/parser
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/JavaScriptCore/Headers
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/JavaScriptCore/PrivateHeaders
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WTF/Headers
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WTF/wtf/java
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source
-I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/PAL/Headers
-isystem /usr/lib/jvm/java/include -isystem /usr/lib/jvm/java/include/linux
-Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread
-Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
-Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
-Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
-Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -I/usr/include/libxml2 -fno-strict-aliasing
-fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections -O2
-g -DNDEBUG -std=c++20 -fPIC -MD -MT
Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
-MF
CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o.d
-o
CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
-c
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp
In file included from
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-1.cpp:8:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jni/jsc/BridgeUtils.cpp:56:10:
fatal error: com_sun_webkit_dom_JSObject.h: No such file or directory
   56 | #include "com_sun_webkit_dom_JSObject.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

That (generated) file seems to be at:
./modules/javafx.web/modules/javafx.web/build/gensrc/headers/javafx.web/com_sun_webkit_dom_JSObject.h

But I can't figure out what is supposed to add that include path to the build.

We are running cmake by hand with:

/usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
-DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
-DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=25

You can see a full build.log here:
https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log

Any help would be greatly appreciated.

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4789 bytes
Desc: S/MIME Cryptographic Signature
URL: 

From angorya at openjdk.org  Mon Oct 13 17:13:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 17:13:14 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 16:51:54 GMT, Johan Vos  wrote:

>> Can this variable be accessed by two threads where one of them doesn't synchronize some other way? If so, then Andy has a point.
>
> I'm aware of the purpose of volatile :)
> However, I'm also aware of the cost of volatile, hence I prefer not to do it unless I know there is a possible scenario where it is needed.
> That is why I'm asking the same question as the one asked by Kevin.

I know you do - the links were added for sake of others :-)

The answer to your question is - I don't know.  If one can guarantee that there is only one thread accessing it, we may need to add a comment (though things might change in the future, and no one reads comments elsewhere in the code).  And if not, then some form of synchronization is mandatory.

I prefer not to think though, and make sure we don't plant booby traps in the code.

BTW, what is the cost of volatile?  0.1 ns?  ;-)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426890844

From jvos at openjdk.org  Mon Oct 13 17:25:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Oct 2025 17:25:07 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 16:36:21 GMT, Kevin Rushforth  wrote:

>> I agree with @johanvos , it's always better to wait for the lock (with a timeout)
>
> Better, sure, but it isn't always possible in practice. There are times where a delay is still needed.
> 
> This test now waits for the lock on the condition that will lead to the thread shutting down. Good. It's still necessary to sleep for a small time to be sure that it has.

As I said in my previous comment, I don't see this as a showstopper for this PR, but since it might help in general, I keep thinking about approaches to remove the sleep.
Wouldn't it be an option here to obtain the JavaFX Application Thread after the `assertTrue(Platform.isFxApplicationThread());` and assign it to e.g. `Thread fxThread` so that instead of the `Util.sleep` we can do `fxThread.join(10)` ? (I might be missing something though)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2426918545

From kevin.rushforth at oracle.com  Mon Oct 13 17:28:57 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Oct 2025 10:28:57 -0700
Subject: Trouble compiling openjfx webkit on Fedora Linux
In-Reply-To: 
References: 
Message-ID: 

This looks like it might be related to moving jdk.jsobject out of the 
JDK to be distributed with JavaFX that I did starting in JDK 24 / JavaFX 24.

A few questions:

1. What JDK are you using to build? Does it have JavaFX modules in it?

2. What OS are you using to build? What version of GCC?

3. What tag or branch in the jfx (or is it jfx25u) repo are you using?

4. What is the gradle command line you used to build?

5. Can you include the logs from the first part of the build and also 
from WebKit's cmake config? It will look something like this:

gradle.gradleVersion: 8.14.2
OS_NAME: linux
OS_ARCH: amd64
JAVA_HOME: 
/scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/jdk-24.0.1
JDK_HOME: 
/scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/jdk-24.0.1
java.runtime.version: 24.0.1+9-30
java version: 24
java build number: 9
jdk.runtime.version: 24.0.1+9-30
jdk version: 24
jdk build: 9
...
UPDATE_STUB_CACHE: false


6. Can you include the logs from WebKit's cmake config? It will look 
something like this:

+? cmake -DPORT="Java" -DCMAKE_BUILD_TYPE=Release 
-DSHOW_BINDINGS_GENERATION_PROGRESS=1 -DDEVELOPER_MODE=ON 
 ?-DENABLE_TOOLS=1 
-DCMAKE_C_COMPILER='/scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/rt/buildSrc/build/build-tools/devkit-linux_x64-gcc14.2.0-OL6.4+1.0.tar/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc' 
-DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64 
-DCMAKE_C_FLAGS='-fno-strict-aliasing -fPIC -fno-omit-frame-pointer 
-fstack-protector -Wextra -Wall -Wformat-security -Wno-unused 
-Wno-parentheses -Werror=trampolines' 
-DCMAKE_CXX_FLAGS='-fno-strict-aliasing -fPIC -fno-omit-frame-pointer 
-fstack-protector -Wextra -Wall -Wformat-security -Wno-unused 
-Wno-parentheses -Werror=trampolines' 
-DCMAKE_SHARED_LINKER_FLAGS='-static-libgcc -static-libstdc++ -shared 
-fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector 
-Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses 
-Werror=trampolines -z relro -Wl,--gc-sections' 
-DCMAKE_EXE_LINKER_FLAGS='-static-libgcc -static-libstdc++ 
-fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector 
-Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses 
-Werror=trampolines -z relro -Wl,--gc-sections' 
-DWEBVIEW_BROWSER_VERSION=18.4 -DJAVAFX_RELEASE_VERSION=26 
"/scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/rt/modules/javafx.web/src/main/native"
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: 
/scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/rt/buildSrc/build/build-tools/devkit-linux_x64-gcc14.2.0-OL6.4+1.0.tar/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc 
- skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
...


-- Kevin

On 10/13/2025 10:00 AM, Orion Poplawski wrote:
> I'm working on trying to re-enable building the openjfx webkit in the Fedora
> Linux package and running into the following error:
>
> [ 42%] Building CXX object
> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
> cd
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/Source/WebCore
> && /usr/bin/g++ -DBUILDING_JAVA__=1 -DBUILDING_WEBKIT=1
> -DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -DDATA_DIR=\"share\"
> -DHAVE_CONFIG_H=1 -DIMAGEIO=1 -DMAX_XML_TREE_DEPTH=2000 -DPAS_BMALLOC=1
> -DSTATICALLY_LINKED_WITH_JavaScriptCore -DSTATICALLY_LINKED_WITH_PAL
> -DSTATICALLY_LINKED_WITH_WTF -DUSE_SYSTEM_MALLOC
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/linux
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/network
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/network/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jni
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebKitLegacy
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/../generated-src/headers
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection/Interfaces
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/InternalAPI
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webgpu/Implementation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/airplay
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/applicationmanifest
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/async-clipboard
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/audiosession
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/badge
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/beacon
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cache
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/compression
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/contact-picker
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cookie-consent
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/cookie-store
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/entriesapi
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/fetch
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/filesystemaccess
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/geolocation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/highlight
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/identity
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasession
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediasource
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/mediastream
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/model-element
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/model-element/dummy
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/notifications
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/permissions
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/pictureinpicture
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/plugins
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/push-api
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/remoteplayback
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/reporting
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/screen-wake-lock
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/speech
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/storage
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/streams
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/web-locks
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webaudio
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/cbor
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webcodecs
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webdatabase
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webdriver
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/websockets
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webtransport
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/webxr
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/accessibility
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/animation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bindings/js
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/c
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jsc
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/contentextensions
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/algorithms
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/keys
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/crypto/parameters
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/calc
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/color
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/parser
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/query
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/color
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/numeric
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/css/typedom/transform
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/cssjit
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/dom
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/dom/messageports
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/domjit
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/editing
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/fileapi
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/history
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/canvas
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/forms
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/parser
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/shadow
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/html/track
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/page
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/inspector/agents/worker
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block/tablewrapper
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/flex
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/floats
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/display
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/invalidation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/ruby
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/text
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration/flex
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/integration/inline
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/layouttree
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/table
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/appcache
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/archive
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/cache
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/loader/icon
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/mathml
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/csp
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/scrolling
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/page/text-extraction
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/animation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/audio
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/calc
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/gamepad
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm/filters
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/software
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/controls
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/iso
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/opentype
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediarecorder
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mediastream
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mock
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/sql
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/text
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/xr
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/plugins
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/line
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/mathml
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/shapes
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/style
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/svg
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/legacy
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/rendering/updating
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/replay
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/storage
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/style
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/animation
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/graphics
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/graphics/filters
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/svg/properties
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/websockets
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/background-fetch
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/context
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/service/server
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/shared
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/workers/shared/context
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/worklets
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/xml
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/xml/parser
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/Modules/gamepad
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/JavaScriptCore/Headers
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/JavaScriptCore/PrivateHeaders
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WTF/Headers
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WTF/wtf/java
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source
> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/PAL/Headers
> -isystem /usr/lib/jvm/java/include -isystem /usr/lib/jvm/java/include/linux
> -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread
> -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
> -Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
> -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
> -Wmissing-format-attribute -Wformat-security -Wcast-align
> -Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
> -Wall -Wno-complain-wrong-lang -Werror=format-security
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -I/usr/include/libxml2 -fno-strict-aliasing
> -fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections -O2
> -g -DNDEBUG -std=c++20 -fPIC -MD -MT
> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
> -MF
> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o.d
> -o
> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp.o
> -c
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp
> In file included from
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-1.cpp:8:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/bridge/jni/jsc/BridgeUtils.cpp:56:10:
> fatal error: com_sun_webkit_dom_JSObject.h: No such file or directory
>     56 | #include "com_sun_webkit_dom_JSObject.h"
>        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
>
> That (generated) file seems to be at:
> ./modules/javafx.web/modules/javafx.web/build/gensrc/headers/javafx.web/com_sun_webkit_dom_JSObject.h
>
> But I can't figure out what is supposed to add that include path to the build.
>
> We are running cmake by hand with:
>
> /usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
> -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
> -DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
> -DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=25
>
> You can see a full build.log here:
> https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log
>
> Any help would be greatly appreciated.
>


From andy.goryachev at oracle.com  Mon Oct 13 17:32:33 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 13 Oct 2025 17:32:33 +0000
Subject: Allowing a cell to commit the value on focus loss
In-Reply-To: <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
Message-ID: 

I wonder if we should find out exactly why onFocusLost does not work in these cases, as expected.  Then, if I understand the proposal correctly, we won't need any API changes.

-andy


From: openjfx-dev  on behalf of John Hendrikx 
Date: Monday, October 13, 2025 at 07:17
To: openjfx-dev at openjdk.org 
Subject: Re: Allowing a cell to commit the value on focus loss


Hi Marius,

This may be unrelated, but it may be problematic to rely on committing values using focus lost:

I've built a lot of code that relies on focus lost to "commit" values to some underlying model.  However, I noticed that a focus lost handler for committing values is insufficient when an action is triggered that doesn't trigger a loss of focus.   For example, if I have a field "email address" and a Button "Send Email", and I have a focus lost handler to commit the email address textfield to an underlying model, then pressing the Button will not trigger that handler and the underlying model may not have been updated with the latest edits.

Solutions to trigger the correct action are all a bit tricky or annoying:

- Query all fields for their current contents as focus lost is not entirely reliable for this purpose
- Have fields update models immediately (which would be on every key press...) -- this is not very efficient, and can get in the way of validation / model restrictions
- Have controls listen to a "COMMIT" event (this is fired at the current focus owner by the Button).  This event may be veto'd if committing the value resulted in a validation error, in which case the button press is cancelled

I don't like any of these, but using the last option at the moment because I like constant updates and having to requery UI components even less...

--John

I noticed however that if you edit some field (it doesn't have to be in a table view, just a regular field), and have a focus lost handler that commits the value, that this focus lost handler is insufficient...

On 13/10/2025 14:53, mariushanl at web.de wrote:
All,

I created an initial poc 1* to support developers to commit the cell value when the focus is lost 2* (including 3*).
More specifically, this gives the maximum flexibility to choose what should happen when the focus is lost or the editing index changed (which may happen when clicking into another cell while editing).
All information mentioned here are also in the description of the PR.

API

- Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the focus is lost or the editing index changed. The default behavior is cancelling the edit, but developers can now override the behavior and allow a `commitEdit` instead
- There are multiple 'events' that can lead to a editing change. Every change will now call `stopEdit`.
It is therefore the responsibility of the developer to decide, when it makes sense to actually commit the value instead of cancelling it. This decision was made as the behavior is manipulating the editing index, but you as a developer can as well. We do not really know what intention led to e.g. a change of the editing index.
- Every `MOUSE_PRESSED` shifts the focus to the cell container, which is undesired in case of editing the cell. So this event is now consumed.
- All `TextField` cells now commit their value (instead of cancel) on focus loss
- `TextField` Escape handling was badly implemented (it was never really called, as the cell container handled Escape before)

Considerations

- I tried to make the API minimal, and without breaking changes (other than the `TextField` cells committing their values, but we may split this up)
- The Cell Container focus behavior is, well, weird right now. That is why consuming the event is needed to better support this PR. One thing we may can consider is using the `focusWithin` property instead for all 4 Cell Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` event. If we decide so, this is needs to be done before merging this PR.
- Clicking the `ScrollBar` now commits/cancels the edit. I checked other applications and this is very common. But something I need to note here. This probably can be fixed in the same way mentioned above (`focusWithin`)
- It might be hard for a developer to exactly know the cause why `stopEdit` is called. This does not seem like a problem, as e.g. for a `TextField`, you normally register listeners for e.g. pressing the Escape key on it, so you keep full control.

Another Approach

- Another Approach I tested could be to request the focus to a cell when clicked/edited, to ensure that the focus listener is ALWAYS called before another cell will reach the editing state. Again, we probably need to change the focus handling to e.g. use the `focusWithin` property. With this approach, we can only call `stopEdit` when the focus changed (since it is now called always), but not when the editing index changed.

1* - https://github.com/openjdk/jfx/pull/1935
2* - https://bugs.openjdk.org/browse/JDK-8089514
3* - https://bugs.openjdk.org/browse/JDK-8089311

-- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Mon Oct 13 17:37:31 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 17:37:31 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 14:03:15 GMT, John Hendrikx  wrote:

>> Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.
>
>> @hjohn The last piece is the CSR. I'll review it once it is ready.
> 
> @kevinrushforth Sorry for the delay, I created the CSR now and moved it to proposed.

@hjohn Now that the CSR has been finalized, this PR will be marked as `ready` once the CSR is approved by the CSR chair.

As @jayathirthrao noted in [this comment](#pullrequestreview-3150607807), he has a corresponding change in a closed-side whitebox test that needs to go in at roughly the same time as this PR. Please coordinate the timing of integration with Jay.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3398469031

From orion at nwra.com  Mon Oct 13 17:42:23 2025
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 13 Oct 2025 11:42:23 -0600
Subject: Trouble compiling openjfx webkit on Fedora Linux
In-Reply-To: 
References: 
 
Message-ID: <3934d63b-be80-4b37-9d25-8fcada2568d7@nwra.com>

On 10/13/25 11:28, Kevin Rushforth wrote:
> This looks like it might be related to moving jdk.jsobject out of the JDK to
> be distributed with JavaFX that I did starting in JDK 24 / JavaFX 24.

I don't think so as I see it in old versions as well.

> A few questions:
> 
> 1. What JDK are you using to build? Does it have JavaFX modules in it?
OpenJDK 25.  It does not have JavaFX modules - that is what this package
provides.>
> 2. What OS are you using to build? What version of GCC?

Fedora Rawhide.  GCC 15.2.1

> 3. What tag or branch in the jfx (or is it jfx25u) repo are you using?

I've tried with a couple different ones:

jfx17u-17.0.13-0
jfx21u-21.0.9+1
jfx25u-25+29

> 
> 4. What is the gradle command line you used to build?

Again, we're not using gradle because it is not packaged for Fedora and we
must build using packaged tools.>
> 5. Can you include the logs from the first part of the build and also from
> WebKit's cmake config? It will look something like this:
> 
> gradle.gradleVersion: 8.14.2
> OS_NAME: linux
> OS_ARCH: amd64
> JAVA_HOME: /scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/
> jdk-24.0.1
> JDK_HOME: /scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/
> jdk-24.0.1
> java.runtime.version: 24.0.1+9-30
> java version: 24
> java build number: 9
> jdk.runtime.version: 24.0.1+9-30
> jdk version: 24
> jdk build: 9
> ...
> UPDATE_STUB_CACHE: false
> 
> 
> 6. Can you include the logs from WebKit's cmake config? It will look something
> like this:

The logs are in the link provided:
https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log

but here you go:

+ /usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
-DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
-DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=21
-- The C compiler identification is GNU 15.2.1
-- The CXX compiler identification is GNU 15.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at Source/cmake/WebKitCommon.cmake:10 (message):
  No CMAKE_BUILD_TYPE value specified, defaulting to RelWithDebInfo.
Call Stack (most recent call first):
  CMakeLists.txt:16 (include)
-- Found Perl: /usr/bin/perl (found suitable version "5.42.0", minimum
required is "5.10.0")
-- Found PerlModules: TRUE  found components: English FindBin JSON::PP
-- Found Python3: /usr/bin/python3.14 (found suitable version "3.14.0",
minimum required is "3.6.0") found components: Interpreter
-- Found Python3: /usr/bin/python3.14 (found version "3.14.0") found
components: Interpreter
-- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY
Ruby_CONFIG_INCLUDE_DIR) (found suitable version "3.4.5", minimum required is
"2.5")
-- Enabling ccache: Couldn't find ccache program. Not enabling it.
-- Performing Test CXX_COMPILER_SUPPORTS_WERROR
-- Performing Test CXX_COMPILER_SUPPORTS_WERROR - Success
-- Performing Test C_COMPILER_SUPPORTS_-fno-strict-aliasing
-- Performing Test C_COMPILER_SUPPORTS_-fno-strict-aliasing - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-strict-aliasing
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-strict-aliasing - Success
-- Performing Test C_COMPILER_SUPPORTS_-fdebug-types-section
-- Performing Test C_COMPILER_SUPPORTS_-fdebug-types-section - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fdebug-types-section
-- Performing Test CXX_COMPILER_SUPPORTS_-fdebug-types-section - Success
-- Performing Test C_COMPILER_SUPPORTS_-fno-exceptions
-- Performing Test C_COMPILER_SUPPORTS_-fno-exceptions - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-exceptions
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-exceptions - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-rtti
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-rtti - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fcoroutines
-- Performing Test CXX_COMPILER_SUPPORTS_-fcoroutines - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fasynchronous-unwind-tables
-- Performing Test CXX_COMPILER_SUPPORTS_-fasynchronous-unwind-tables - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wno-tautological-compare
-- Performing Test C_COMPILER_SUPPORTS_-Wno-tautological-compare - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-tautological-compare
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-tautological-compare - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wcast-align
-- Performing Test C_COMPILER_SUPPORTS_-Wcast-align - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wformat-security
-- Performing Test C_COMPILER_SUPPORTS_-Wformat-security - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wmissing-format-attribute
-- Performing Test C_COMPILER_SUPPORTS_-Wmissing-format-attribute - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wpointer-arith
-- Performing Test C_COMPILER_SUPPORTS_-Wpointer-arith - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wundef
-- Performing Test C_COMPILER_SUPPORTS_-Wundef - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wcast-align
-- Performing Test CXX_COMPILER_SUPPORTS_-Wcast-align - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wformat-security
-- Performing Test CXX_COMPILER_SUPPORTS_-Wformat-security - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wmissing-format-attribute
-- Performing Test CXX_COMPILER_SUPPORTS_-Wmissing-format-attribute - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wpointer-arith
-- Performing Test CXX_COMPILER_SUPPORTS_-Wpointer-arith - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wundef
-- Performing Test CXX_COMPILER_SUPPORTS_-Wundef - Success
-- Performing Test C_COMPILER_SUPPORTS_-Qunused-arguments
-- Performing Test C_COMPILER_SUPPORTS_-Qunused-arguments - Failed
-- Performing Test C_COMPILER_SUPPORTS_-Wno-maybe-uninitialized
-- Performing Test C_COMPILER_SUPPORTS_-Wno-maybe-uninitialized - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wno-parentheses-equality
-- Performing Test C_COMPILER_SUPPORTS_-Wno-parentheses-equality - Failed
-- Performing Test C_COMPILER_SUPPORTS_-Wno-misleading-indentation
-- Performing Test C_COMPILER_SUPPORTS_-Wno-misleading-indentation - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wno-psabi
-- Performing Test C_COMPILER_SUPPORTS_-Wno-psabi - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Qunused-arguments
-- Performing Test CXX_COMPILER_SUPPORTS_-Qunused-arguments - Failed
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-maybe-uninitialized
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-maybe-uninitialized - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-parentheses-equality
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-parentheses-equality - Failed
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-misleading-indentation
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-misleading-indentation - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-psabi
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-psabi - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-noexcept-type
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-noexcept-type - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wno-expansion-to-defined
-- Performing Test C_COMPILER_SUPPORTS_-Wno-expansion-to-defined - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-expansion-to-defined
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-expansion-to-defined - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-array-bounds
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-array-bounds - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-nonnull
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-nonnull - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overflow
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overflow - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overread
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overread - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-odr
-- Performing Test CXX_COMPILER_SUPPORTS_-Wno-odr - Success
-- Performing Test C_COMPILER_SUPPORTS_-fmax-errors__20
-- Performing Test C_COMPILER_SUPPORTS_-fmax-errors__20 - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fmax-errors__20
-- Performing Test CXX_COMPILER_SUPPORTS_-fmax-errors__20 - Success
-- Performing Test C_COMPILER_SUPPORTS_-pipe
-- Performing Test C_COMPILER_SUPPORTS_-pipe - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-pipe
-- Performing Test CXX_COMPILER_SUPPORTS_-pipe - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wall
-- Performing Test C_COMPILER_SUPPORTS_-Wall - Success
-- Performing Test C_COMPILER_SUPPORTS_-Wextra
-- Performing Test C_COMPILER_SUPPORTS_-Wextra - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wall
-- Performing Test CXX_COMPILER_SUPPORTS_-Wall - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-Wextra
-- Performing Test CXX_COMPILER_SUPPORTS_-Wextra - Success
-- Performing Test C_COMPILER_SUPPORTS_-fcolor-diagnostics
-- Performing Test C_COMPILER_SUPPORTS_-fcolor-diagnostics - Failed
-- Performing Test C_COMPILER_SUPPORTS_-fdiagnostics-color__always
-- Performing Test C_COMPILER_SUPPORTS_-fdiagnostics-color__always - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fcolor-diagnostics
-- Performing Test CXX_COMPILER_SUPPORTS_-fcolor-diagnostics - Failed
-- Performing Test CXX_COMPILER_SUPPORTS_-fdiagnostics-color__always
-- Performing Test CXX_COMPILER_SUPPORTS_-fdiagnostics-color__always - Success
-- Performing Test ATOMICS_ARE_BUILTIN
-- Performing Test ATOMICS_ARE_BUILTIN - Failed
-- Performing Test ATOMICS_REQUIRE_LIBATOMIC
-- Performing Test ATOMICS_REQUIRE_LIBATOMIC - Success
-- Performing Test STD_FILESYSTEM_IS_AVAILABLE
-- Performing Test STD_FILESYSTEM_IS_AVAILABLE - Success
-- Performing Test HAVE_FLOAT16
-- Performing Test HAVE_FLOAT16 - Success
-- Linker variant in use: BFD
--   Linker supports thin archives - TRUE
--   Linker supports split debug info - TRUE
--   Linker supports --gdb-index - FALSE
--   Linker supports --disable-new-dtags - TRUE
--   Linker supports --gc-sections - TRUE
-- Archiver variant in use: BFD
--   Archiver supports thin archives - TRUE
-- Performing Test C_COMPILER_SUPPORTS_-ffunction-sections
-- Performing Test C_COMPILER_SUPPORTS_-ffunction-sections - Success
-- Performing Test C_COMPILER_SUPPORTS_-fdata-sections
-- Performing Test C_COMPILER_SUPPORTS_-fdata-sections - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-ffunction-sections
-- Performing Test CXX_COMPILER_SUPPORTS_-ffunction-sections - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fdata-sections
-- Performing Test CXX_COMPILER_SUPPORTS_-fdata-sections - Success
-- Looking for features.h
-- Looking for features.h - found
-- Looking for errno.h
-- Looking for errno.h - found
-- Looking for langinfo.h
-- Looking for langinfo.h - found
-- Looking for sys/mman.h
-- Looking for sys/mman.h - found
-- Looking for pthread_np.h
-- Looking for pthread_np.h - not found
-- Looking for sys/param.h
-- Looking for sys/param.h - found
-- Looking for sys/time.h
-- Looking for sys/time.h - found
-- Looking for sys/timeb.h
-- Looking for sys/timeb.h - found
-- Looking for linux/memfd.h
-- Looking for linux/memfd.h - found
-- Looking for _aligned_malloc
-- Looking for _aligned_malloc - not found
-- Looking for localtime_r
-- Looking for localtime_r - found
-- Looking for malloc_trim
-- Looking for malloc_trim - found
-- Looking for statx
-- Looking for statx - found
-- Looking for strnstr
-- Looking for strnstr - not found
-- Looking for timegm
-- Looking for timegm - found
-- Looking for vasprintf
-- Looking for vasprintf - found
-- Looking for regexec
-- Looking for regexec - found
-- Looking for pthread_main_np
-- Looking for pthread_main_np - not found
-- Looking for MAP_ALIGNED
-- Looking for MAP_ALIGNED - not found
-- Looking for SHM_ANON
-- Looking for SHM_ANON - not found
-- Looking for timingsafe_bcmp
-- Looking for timingsafe_bcmp - not found
-- Looking for SIGTRAP
-- Looking for SIGTRAP - found
-- Performing Test HAVE_STAT_BIRTHTIME_value
-- Performing Test HAVE_STAT_BIRTHTIME_value - Failed
-- Performing Test HAVE_TM_GMTOFF_value
-- Performing Test HAVE_TM_GMTOFF_value - Success
-- Performing Test HAVE_TM_ZONE_value
-- Performing Test HAVE_TM_ZONE_value - Success
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of __int128_t
-- Check size of __int128_t - done
-- Found JNI: /usr/lib/jvm/java/include  found components: AWT JVM
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Disabling ENABLE_WEBASSEMBLY_BBQJIT since ENABLE_FTL_JIT is disabled.
-- Disabling ENABLE_WEBASSEMBLY_OMGJIT since ENABLE_FTL_JIT is disabled.
-- Found Gperf: /usr/bin/gperf (Required is at least version "3.0.1")
-- Using platform-specific CMakeLists:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformJava.cmake
-- Copying generate-unified-source-bundles.rb to:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WTF/Scripts
-- Using platform-specific CMakeLists:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/JavaScriptCore/PlatformJava.cmake
-- Performing Test CXX_COMPILER_SUPPORTS_-ffp-contract__off
-- Performing Test CXX_COMPILER_SUPPORTS_-ffp-contract__off - Success
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-slp-vectorize
-- Performing Test CXX_COMPILER_SUPPORTS_-fno-slp-vectorize - Failed
-- Enabling asm postprocessing
-- Using source list file: Sources.txt
-- Using platform-specific CMakeLists:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/PlatformJava.cmake
-- Looking for shm_open
-- Looking for shm_open - found
-- Using platform-specific CMakeLists:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/PlatformJava.cmake
-- Using system malloc
-- Using source list file: Sources.txt
-- Using source list file: SourcesJava.txt
-- Using platform-specific CMakeLists:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebKitLegacy/PlatformJava.cmake
-- Platform-specific CMakeLists not found:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/PlatformJava.cmake
-- Platform-specific CMakeLists not found:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/PlatformJava.cmake
-- Platform-specific CMakeLists not found:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/TestRunnerShared/java/PlatformJava.cmake
-- Platform-specific CMakeLists not found:
/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/DumpRenderTree/java/PlatformJava.cmake
-- Enabled features:
--  ENABLE_DATALIST_ELEMENT ....................... OFF
--  ENABLE_DRAG_SUPPORT                             ON
--  ENABLE_FTL_JIT ................................ OFF
--  ENABLE_TOUCH_EVENTS                             OFF
--  ENABLE_VIDEO .................................. ON
-- Configuring done (33.9s)
-- Generating done (9.0s)

> -- Kevin

Thanks for taking a look!

> 
> On 10/13/2025 10:00 AM, Orion Poplawski wrote:
>> I'm working on trying to re-enable building the openjfx webkit in the Fedora
>> Linux package and running into the following error:
>>
>> [ 42%] Building CXX object
>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-
>> sources/UnifiedSource-2fa1981b-2.cpp.o
>> cd
>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/Source/WebCore
>> && /usr/bin/g++ -DBUILDING_JAVA__=1 -DBUILDING_WEBKIT=1
>> -DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -DDATA_DIR=\"share\"
>> -DHAVE_CONFIG_H=1 -DIMAGEIO=1 -DMAX_XML_TREE_DEPTH=2000 -DPAS_BMALLOC=1
>> -DSTATICALLY_LINKED_WITH_JavaScriptCore -DSTATICALLY_LINKED_WITH_PAL
>> -DSTATICALLY_LINKED_WITH_WTF -DUSE_SYSTEM_MALLOC
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/linux
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/network
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/network/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bindings/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/page/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bridge/jni
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebKitLegacy
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/../generated-src/headers
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/WebCore/DerivedSources
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection/Interfaces
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu/InternalAPI
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu/Implementation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/airplay
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/applepay
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/applicationmanifest
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/async-clipboard
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/audiosession
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/badge
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/beacon
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/cache
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/compression
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/contact-picker
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/cookie-consent
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/cookie-store
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/entriesapi
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/fetch
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/filesystemaccess
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/geolocation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/highlight
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/identity
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediasession
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediasource
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/mediastream
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/model-element
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/model-element/dummy
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/notifications
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/permissions
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/pictureinpicture
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/plugins
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/push-api
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/remoteplayback
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/reporting
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/screen-wake-lock
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/speech
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/storage
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/streams
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/web-locks
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webaudio
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn/cbor
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webcodecs
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webdatabase
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webdriver
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/websockets
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webtransport
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/webxr
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/accessibility
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/animation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bindings
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bindings/js
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bridge
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bridge/c
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bridge/jsc
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/contentextensions
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/crypto
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/crypto/algorithms
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/crypto/keys
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/crypto/parameters
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/calc
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/color
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/parser
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/query
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/typedom
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/typedom/color
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/typedom/numeric
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/css/typedom/transform
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/cssjit
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/dom
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/dom/messageports
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/domjit
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/editing
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/fileapi
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/history
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html/canvas
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html/forms
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html/parser
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html/shadow
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/html/track
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/inspector
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/inspector/agents
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/inspector/agents/page
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/inspector/agents/worker
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block/
>> tablewrapper
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/flex
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/floats
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/
>> display
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/
>> invalidation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/ruby
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/text
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/integration
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/integration/flex
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/integration/inline
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/layouttree
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/table
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader/appcache
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader/archive
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader/cache
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/loader/icon
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/mathml
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/page
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/page/csp
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/page/scrolling
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/page/text-extraction
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/animation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/audio
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/calc
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/gamepad
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm/filters
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/filters
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/software
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/controls
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/iso
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/opentype
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/mediarecorder
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/mediastream
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/mock
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/sql
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/text
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/xr
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/plugins
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/line
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/mathml
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/shapes
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/style
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/svg
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/svg/legacy
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/rendering/updating
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/replay
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/storage
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/style
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/svg
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/svg/animation
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/svg/graphics
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/svg/graphics/filters
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/svg/properties
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/websockets
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/service
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/service/background-fetch
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/service/context
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/service/server
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/shared
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/workers/shared/context
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/worklets
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/xml
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/xml/parser
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/Modules/gamepad
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/JavaScriptCore/Headers
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/JavaScriptCore/PrivateHeaders
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/WTF/Headers
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WTF/wtf/java
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source
>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/PAL/Headers
>> -isystem /usr/lib/jvm/java/include -isystem /usr/lib/jvm/java/include/linux
>> -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread
>> -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
>> -Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
>> -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
>> -Wmissing-format-attribute -Wformat-security -Wcast-align
>> -Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
>> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
>> -Wall -Wno-complain-wrong-lang -Werror=format-security
>> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
>> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
>> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
>> -mno-omit-leaf-frame-pointer -I/usr/include/libxml2 -fno-strict-aliasing
>> -fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections -O2
>> -g -DNDEBUG -std=c++20 -fPIC -MD -MT
>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-
>> sources/UnifiedSource-2fa1981b-2.cpp.o
>> -MF
>> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/
>> UnifiedSource-2fa1981b-2.cpp.o.d
>> -o
>> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/
>> UnifiedSource-2fa1981b-2.cpp.o
>> -c
>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp
>> In file included from
>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>> build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-1.cpp:8:
>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>> javafx.web/src/main/native/Source/WebCore/bridge/jni/jsc/BridgeUtils.cpp:56:10:
>> fatal error: com_sun_webkit_dom_JSObject.h: No such file or directory
>> ??? 56 | #include "com_sun_webkit_dom_JSObject.h"
>> ?????? |????????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> compilation terminated.
>>
>> That (generated) file seems to be at:
>> ./modules/javafx.web/modules/javafx.web/build/gensrc/headers/javafx.web/
>> com_sun_webkit_dom_JSObject.h
>>
>> But I can't figure out what is supposed to add that include path to the build.
>>
>> We are running cmake by hand with:
>>
>> /usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
>> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
>> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
>> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
>> -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
>> -DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
>> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
>> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
>> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
>> -DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
>> -DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=25
>>
>> You can see a full build.log here:
>> https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log
>>
>> Any help would be greatly appreciated.
>>
> 



-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4789 bytes
Desc: S/MIME Cryptographic Signature
URL: 

From kcr at openjdk.org  Mon Oct 13 18:24:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Oct 2025 18:24:18 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
 
 
 
 
Message-ID: <6KI8STxuwzllH-r2PAvdNt45ygJQI1cjTIKeSjJiM14=.842c3ff4-751b-431e-b079-b23d2606e3a8@github.com>

On Mon, 13 Oct 2025 17:22:08 GMT, Johan Vos  wrote:

>> Better, sure, but it isn't always possible in practice. There are times where a delay is still needed.
>> 
>> This test now waits for the lock on the condition that will lead to the thread shutting down. Good. It's still necessary to sleep for a small time to be sure that it has.
>
> As I said in my previous comment, I don't see this as a showstopper for this PR, but since it might help in general, I keep thinking about approaches to remove the sleep.
> Wouldn't it be an option here to obtain the JavaFX Application Thread after the `assertTrue(Platform.isFxApplicationThread());` and assign it to e.g. `Thread fxThread` so that instead of the `Util.sleep` we can do `fxThread.join(10)` ? (I might be missing something though)

Yes, something like what you describe might work in this case.

As for the more general problem, which goes well beyond this PR, there are many places in our tests where we do need sleeps. They fall into two cases

1. Lack of a feature that provides a deterministic way to know when something has occurred. Implementing the missing functionality could allow us to replace sleeps with something more deterministic.
2. Inherent limitations where there cannot be a deterministic way to know when something has occurred.

Many, if not most, of the instances of 1 could be addressed with an implementation of `Robot::waitForIdle`. It's a long-standing feature request. It's not rocket science to implement, but isn't trivial either.

Most of the instances of 2 are due to either A) platform delay in realizing certain window system operations (show/hide/minimize/maximize/to-front/etc); or B) inherent GC non-determinism.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2427030820

From kevin.rushforth at oracle.com  Mon Oct 13 18:26:28 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Oct 2025 11:26:28 -0700
Subject: [External] : Re: Trouble compiling openjfx webkit on Fedora Linux
In-Reply-To: <3934d63b-be80-4b37-9d25-8fcada2568d7@nwra.com>
References: 
 
 <3934d63b-be80-4b37-9d25-8fcada2568d7@nwra.com>
Message-ID: <12828462-c05a-45c1-b67e-5be23d35e92a@oracle.com>



On 10/13/2025 10:42 AM, Orion Poplawski wrote:
> On 10/13/25 11:28, Kevin Rushforth wrote:
>> This looks like it might be related to moving jdk.jsobject out of the JDK to
>> be distributed with JavaFX that I did starting in JDK 24 / JavaFX 24.
> I don't think so as I see it in old versions as well.

Yes, I looked more closely at your failure, and you are right. It isn't 
related.

>> A few questions:
>>
>> 1. What JDK are you using to build? Does it have JavaFX modules in it?
> OpenJDK 25.  It does not have JavaFX modules - that is what this package
> provides.>

OK.

>> 2. What OS are you using to build? What version of GCC?
> Fedora Rawhide.  GCC 15.2.1

You may or may not run into any GCC 15 failures (we had several with GCC 
14, which are now all fixed). If you do, feel free to let us know.

>> 3. What tag or branch in the jfx (or is it jfx25u) repo are you using?
> I've tried with a couple different ones:
>
> jfx17u-17.0.13-0
> jfx21u-21.0.9+1
> jfx25u-25+29

OK.

>> 4. What is the gradle command line you used to build?
> Again, we're not using gradle because it is not packaged for Fedora and we
> must build using packaged tools.>

You are in uncharted waters then. How are you building the class files 
and the modules if you don't run "gradle"? It isn't as simple as running 
"javac". I don't have the time to help you debug your environment, but I 
would recommend looking at what the gradle build does when it builds the 
class files. Specifically, the header files that are missing and causing 
your build failure are generated as part of building the Java classes 
for the javafx.web module (which must be built before the native code 
can be built).

I didn't spot anything amiss in the cmake output, so it might be that 
once you run javac to build the classes and header files you'll be able 
to proceed.

Good luck.

-- Kevin


>> 5. Can you include the logs from the first part of the build and also from
>> WebKit's cmake config? It will look something like this:
>>
>> gradle.gradleVersion: 8.14.2
>> OS_NAME: linux
>> OS_ARCH: amd64
>> JAVA_HOME: /scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/
>> jdk-24.0.1
>> JDK_HOME: /scratch/jenkins/workspace/jfx-dev/label/lin-ol8-x64/jfx/bootjdk/
>> jdk-24.0.1
>> java.runtime.version: 24.0.1+9-30
>> java version: 24
>> java build number: 9
>> jdk.runtime.version: 24.0.1+9-30
>> jdk version: 24
>> jdk build: 9
>> ...
>> UPDATE_STUB_CACHE: false
>>
>>
>> 6. Can you include the logs from WebKit's cmake config? It will look something
>> like this:
> The logs are in the link provided:
> https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log
>
> but here you go:
>
> + /usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
> -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
> -DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
> -DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=21
> -- The C compiler identification is GNU 15.2.1
> -- The CXX compiler identification is GNU 15.2.1
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/gcc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/g++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> CMake Warning at Source/cmake/WebKitCommon.cmake:10 (message):
>    No CMAKE_BUILD_TYPE value specified, defaulting to RelWithDebInfo.
> Call Stack (most recent call first):
>    CMakeLists.txt:16 (include)
> -- Found Perl: /usr/bin/perl (found suitable version "5.42.0", minimum
> required is "5.10.0")
> -- Found PerlModules: TRUE  found components: English FindBin JSON::PP
> -- Found Python3: /usr/bin/python3.14 (found suitable version "3.14.0",
> minimum required is "3.6.0") found components: Interpreter
> -- Found Python3: /usr/bin/python3.14 (found version "3.14.0") found
> components: Interpreter
> -- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY
> Ruby_CONFIG_INCLUDE_DIR) (found suitable version "3.4.5", minimum required is
> "2.5")
> -- Enabling ccache: Couldn't find ccache program. Not enabling it.
> -- Performing Test CXX_COMPILER_SUPPORTS_WERROR
> -- Performing Test CXX_COMPILER_SUPPORTS_WERROR - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fno-strict-aliasing
> -- Performing Test C_COMPILER_SUPPORTS_-fno-strict-aliasing - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-strict-aliasing
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-strict-aliasing - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fdebug-types-section
> -- Performing Test C_COMPILER_SUPPORTS_-fdebug-types-section - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdebug-types-section
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdebug-types-section - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fno-exceptions
> -- Performing Test C_COMPILER_SUPPORTS_-fno-exceptions - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-exceptions
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-exceptions - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-rtti
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-rtti - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fcoroutines
> -- Performing Test CXX_COMPILER_SUPPORTS_-fcoroutines - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fasynchronous-unwind-tables
> -- Performing Test CXX_COMPILER_SUPPORTS_-fasynchronous-unwind-tables - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-tautological-compare
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-tautological-compare - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-tautological-compare
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-tautological-compare - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wcast-align
> -- Performing Test C_COMPILER_SUPPORTS_-Wcast-align - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wformat-security
> -- Performing Test C_COMPILER_SUPPORTS_-Wformat-security - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wmissing-format-attribute
> -- Performing Test C_COMPILER_SUPPORTS_-Wmissing-format-attribute - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wpointer-arith
> -- Performing Test C_COMPILER_SUPPORTS_-Wpointer-arith - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wundef
> -- Performing Test C_COMPILER_SUPPORTS_-Wundef - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wcast-align
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wcast-align - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wformat-security
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wformat-security - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wmissing-format-attribute
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wmissing-format-attribute - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wpointer-arith
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wpointer-arith - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wundef
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wundef - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Qunused-arguments
> -- Performing Test C_COMPILER_SUPPORTS_-Qunused-arguments - Failed
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-maybe-uninitialized
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-maybe-uninitialized - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-parentheses-equality
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-parentheses-equality - Failed
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-misleading-indentation
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-misleading-indentation - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-psabi
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-psabi - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Qunused-arguments
> -- Performing Test CXX_COMPILER_SUPPORTS_-Qunused-arguments - Failed
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-maybe-uninitialized
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-maybe-uninitialized - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-parentheses-equality
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-parentheses-equality - Failed
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-misleading-indentation
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-misleading-indentation - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-psabi
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-psabi - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-noexcept-type
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-noexcept-type - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-expansion-to-defined
> -- Performing Test C_COMPILER_SUPPORTS_-Wno-expansion-to-defined - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-expansion-to-defined
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-expansion-to-defined - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-array-bounds
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-array-bounds - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-nonnull
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-nonnull - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overflow
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overflow - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overread
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-stringop-overread - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-odr
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wno-odr - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fmax-errors__20
> -- Performing Test C_COMPILER_SUPPORTS_-fmax-errors__20 - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fmax-errors__20
> -- Performing Test CXX_COMPILER_SUPPORTS_-fmax-errors__20 - Success
> -- Performing Test C_COMPILER_SUPPORTS_-pipe
> -- Performing Test C_COMPILER_SUPPORTS_-pipe - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-pipe
> -- Performing Test CXX_COMPILER_SUPPORTS_-pipe - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wall
> -- Performing Test C_COMPILER_SUPPORTS_-Wall - Success
> -- Performing Test C_COMPILER_SUPPORTS_-Wextra
> -- Performing Test C_COMPILER_SUPPORTS_-Wextra - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wall
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wall - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wextra
> -- Performing Test CXX_COMPILER_SUPPORTS_-Wextra - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fcolor-diagnostics
> -- Performing Test C_COMPILER_SUPPORTS_-fcolor-diagnostics - Failed
> -- Performing Test C_COMPILER_SUPPORTS_-fdiagnostics-color__always
> -- Performing Test C_COMPILER_SUPPORTS_-fdiagnostics-color__always - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fcolor-diagnostics
> -- Performing Test CXX_COMPILER_SUPPORTS_-fcolor-diagnostics - Failed
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdiagnostics-color__always
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdiagnostics-color__always - Success
> -- Performing Test ATOMICS_ARE_BUILTIN
> -- Performing Test ATOMICS_ARE_BUILTIN - Failed
> -- Performing Test ATOMICS_REQUIRE_LIBATOMIC
> -- Performing Test ATOMICS_REQUIRE_LIBATOMIC - Success
> -- Performing Test STD_FILESYSTEM_IS_AVAILABLE
> -- Performing Test STD_FILESYSTEM_IS_AVAILABLE - Success
> -- Performing Test HAVE_FLOAT16
> -- Performing Test HAVE_FLOAT16 - Success
> -- Linker variant in use: BFD
> --   Linker supports thin archives - TRUE
> --   Linker supports split debug info - TRUE
> --   Linker supports --gdb-index - FALSE
> --   Linker supports --disable-new-dtags - TRUE
> --   Linker supports --gc-sections - TRUE
> -- Archiver variant in use: BFD
> --   Archiver supports thin archives - TRUE
> -- Performing Test C_COMPILER_SUPPORTS_-ffunction-sections
> -- Performing Test C_COMPILER_SUPPORTS_-ffunction-sections - Success
> -- Performing Test C_COMPILER_SUPPORTS_-fdata-sections
> -- Performing Test C_COMPILER_SUPPORTS_-fdata-sections - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-ffunction-sections
> -- Performing Test CXX_COMPILER_SUPPORTS_-ffunction-sections - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdata-sections
> -- Performing Test CXX_COMPILER_SUPPORTS_-fdata-sections - Success
> -- Looking for features.h
> -- Looking for features.h - found
> -- Looking for errno.h
> -- Looking for errno.h - found
> -- Looking for langinfo.h
> -- Looking for langinfo.h - found
> -- Looking for sys/mman.h
> -- Looking for sys/mman.h - found
> -- Looking for pthread_np.h
> -- Looking for pthread_np.h - not found
> -- Looking for sys/param.h
> -- Looking for sys/param.h - found
> -- Looking for sys/time.h
> -- Looking for sys/time.h - found
> -- Looking for sys/timeb.h
> -- Looking for sys/timeb.h - found
> -- Looking for linux/memfd.h
> -- Looking for linux/memfd.h - found
> -- Looking for _aligned_malloc
> -- Looking for _aligned_malloc - not found
> -- Looking for localtime_r
> -- Looking for localtime_r - found
> -- Looking for malloc_trim
> -- Looking for malloc_trim - found
> -- Looking for statx
> -- Looking for statx - found
> -- Looking for strnstr
> -- Looking for strnstr - not found
> -- Looking for timegm
> -- Looking for timegm - found
> -- Looking for vasprintf
> -- Looking for vasprintf - found
> -- Looking for regexec
> -- Looking for regexec - found
> -- Looking for pthread_main_np
> -- Looking for pthread_main_np - not found
> -- Looking for MAP_ALIGNED
> -- Looking for MAP_ALIGNED - not found
> -- Looking for SHM_ANON
> -- Looking for SHM_ANON - not found
> -- Looking for timingsafe_bcmp
> -- Looking for timingsafe_bcmp - not found
> -- Looking for SIGTRAP
> -- Looking for SIGTRAP - found
> -- Performing Test HAVE_STAT_BIRTHTIME_value
> -- Performing Test HAVE_STAT_BIRTHTIME_value - Failed
> -- Performing Test HAVE_TM_GMTOFF_value
> -- Performing Test HAVE_TM_GMTOFF_value - Success
> -- Performing Test HAVE_TM_ZONE_value
> -- Performing Test HAVE_TM_ZONE_value - Success
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of __int128_t
> -- Check size of __int128_t - done
> -- Found JNI: /usr/lib/jvm/java/include  found components: AWT JVM
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
> -- Found Threads: TRUE
> -- Disabling ENABLE_WEBASSEMBLY_BBQJIT since ENABLE_FTL_JIT is disabled.
> -- Disabling ENABLE_WEBASSEMBLY_OMGJIT since ENABLE_FTL_JIT is disabled.
> -- Found Gperf: /usr/bin/gperf (Required is at least version "3.0.1")
> -- Using platform-specific CMakeLists:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformJava.cmake
> -- Copying generate-unified-source-bundles.rb to:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build/WTF/Scripts
> -- Using platform-specific CMakeLists:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/JavaScriptCore/PlatformJava.cmake
> -- Performing Test CXX_COMPILER_SUPPORTS_-ffp-contract__off
> -- Performing Test CXX_COMPILER_SUPPORTS_-ffp-contract__off - Success
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-slp-vectorize
> -- Performing Test CXX_COMPILER_SUPPORTS_-fno-slp-vectorize - Failed
> -- Enabling asm postprocessing
> -- Using source list file: Sources.txt
> -- Using platform-specific CMakeLists:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/PAL/pal/PlatformJava.cmake
> -- Looking for shm_open
> -- Looking for shm_open - found
> -- Using platform-specific CMakeLists:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebCore/PlatformJava.cmake
> -- Using system malloc
> -- Using source list file: Sources.txt
> -- Using source list file: SourcesJava.txt
> -- Using platform-specific CMakeLists:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/WebKitLegacy/PlatformJava.cmake
> -- Platform-specific CMakeLists not found:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Source/PlatformJava.cmake
> -- Platform-specific CMakeLists not found:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/PlatformJava.cmake
> -- Platform-specific CMakeLists not found:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/TestRunnerShared/java/PlatformJava.cmake
> -- Platform-specific CMakeLists not found:
> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/javafx.web/src/main/native/Tools/DumpRenderTree/java/PlatformJava.cmake
> -- Enabled features:
> --  ENABLE_DATALIST_ELEMENT ....................... OFF
> --  ENABLE_DRAG_SUPPORT                             ON
> --  ENABLE_FTL_JIT ................................ OFF
> --  ENABLE_TOUCH_EVENTS                             OFF
> --  ENABLE_VIDEO .................................. ON
> -- Configuring done (33.9s)
> -- Generating done (9.0s)
>
>> -- Kevin
> Thanks for taking a look!
>
>> On 10/13/2025 10:00 AM, Orion Poplawski wrote:
>>> I'm working on trying to re-enable building the openjfx webkit in the Fedora
>>> Linux package and running into the following error:
>>>
>>> [ 42%] Building CXX object
>>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-
>>> sources/UnifiedSource-2fa1981b-2.cpp.o
>>> cd
>>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/Source/WebCore
>>> && /usr/bin/g++ -DBUILDING_JAVA__=1 -DBUILDING_WEBKIT=1
>>> -DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -DDATA_DIR=\"share\"
>>> -DHAVE_CONFIG_H=1 -DIMAGEIO=1 -DMAX_XML_TREE_DEPTH=2000 -DPAS_BMALLOC=1
>>> -DSTATICALLY_LINKED_WITH_JavaScriptCore -DSTATICALLY_LINKED_WITH_PAL
>>> -DSTATICALLY_LINKED_WITH_WTF -DUSE_SYSTEM_MALLOC
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/linux
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/network
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/network/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bindings/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/page/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bridge/jni
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebKitLegacy
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/../generated-src/headers
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-build
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/WebCore/DerivedSources
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/ShapeDetection/Interfaces
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu/InternalAPI
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webgpu/Implementation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/airplay
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/applepay
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/applepay/paymentrequest
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/applicationmanifest
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/async-clipboard
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/audiosession
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/badge
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/beacon
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/cache
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/compression
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/contact-picker
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/cookie-consent
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/cookie-store
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/credentialmanagement
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/encryptedmedia/legacy
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/entriesapi
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/fetch
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/filesystemaccess
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/geolocation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/highlight
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/identity
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/client
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/server
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/indexeddb/shared
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediacapabilities
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediacontrols
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediarecorder
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediasession
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediasource
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/mediastream
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/model-element
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/model-element/dummy
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/navigatorcontentutils
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/notifications
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/paymentrequest
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/permissions
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/pictureinpicture
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/plugins
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/push-api
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/remoteplayback
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/reporting
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/screen-wake-lock
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/speech
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/storage
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/streams
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/web-locks
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webaudio
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn/cbor
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webauthn/fido
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webcodecs
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webdatabase
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webdriver
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/websockets
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webtransport
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/webxr
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/accessibility
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/accessibility/isolatedtree
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/animation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bindings
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bindings/js
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bridge
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bridge/c
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bridge/jsc
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/contentextensions
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/crypto
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/crypto/algorithms
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/crypto/keys
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/crypto/parameters
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/calc
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/color
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/parser
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/query
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/typedom
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/typedom/color
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/typedom/numeric
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/css/typedom/transform
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/cssjit
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/dom
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/dom/messageports
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/domjit
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/editing
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/fileapi
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/history
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html/canvas
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html/forms
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html/parser
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html/shadow
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/html/track
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/inspector
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/inspector/agents
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/inspector/agents/page
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/inspector/agents/worker
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/block/
>>> tablewrapper
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/flex
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/floats
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/
>>> display
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/
>>> invalidation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/ruby
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/inline/text
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/integration
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/integration/flex
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/integration/inline
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/layouttree
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/layout/formattingContexts/table
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader/appcache
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader/archive
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader/archive/mhtml
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader/cache
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/loader/icon
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/mathml
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/page
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/page/csp
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/page/scrolling
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/page/text-extraction
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/animation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/audio
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/calc
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/encryptedmedia
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/gamepad
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/cpu/arm/filters
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/displaylists
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/filters
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/filters/software
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/controls
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/iso
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/opentype
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/transforms
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/mediacapabilities
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/mediarecorder
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/mediastream
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/mock
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/mock/mediasource
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/sql
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/text
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/xr
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/plugins
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/line
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/mathml
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/shapes
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/style
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/svg
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/svg/legacy
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/rendering/updating
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/replay
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/storage
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/style
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/svg
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/svg/animation
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/svg/graphics
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/svg/graphics/filters
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/svg/properties
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/websockets
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/service
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/service/background-fetch
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/service/context
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/service/server
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/shared
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/workers/shared/context
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/worklets
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/xml
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/xml/parser
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/Modules/gamepad
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/texmap
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/platform/graphics/nicosia
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/JavaScriptCore/Headers
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/JavaScriptCore/PrivateHeaders
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/WTF/Headers
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WTF/wtf/java
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source
>>> -I/builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/PAL/Headers
>>> -isystem /usr/lib/jvm/java/include -isystem /usr/lib/jvm/java/include/linux
>>> -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr -Wno-stringop-overread
>>> -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds
>>> -Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
>>> -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith
>>> -Wmissing-format-attribute -Wformat-security -Wcast-align
>>> -Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
>>> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
>>> -Wall -Wno-complain-wrong-lang -Werror=format-security
>>> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
>>> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
>>> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
>>> -mno-omit-leaf-frame-pointer -I/usr/include/libxml2 -fno-strict-aliasing
>>> -fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections -O2
>>> -g -DNDEBUG -std=c++20 -fPIC -MD -MT
>>> Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-
>>> sources/UnifiedSource-2fa1981b-2.cpp.o
>>> -MF
>>> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/
>>> UnifiedSource-2fa1981b-2.cpp.o.d
>>> -o
>>> CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/
>>> UnifiedSource-2fa1981b-2.cpp.o
>>> -c
>>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-2.cpp
>>> In file included from
>>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/redhat-linux-
>>> build/WebCore/DerivedSources/unified-sources/UnifiedSource-2fa1981b-1.cpp:8:
>>> /builddir/build/BUILD/openjfx-25-25.29-build/jfx25u-25-29/modules/
>>> javafx.web/src/main/native/Source/WebCore/bridge/jni/jsc/BridgeUtils.cpp:56:10:
>>> fatal error: com_sun_webkit_dom_JSObject.h: No such file or directory
>>>  ??? 56 | #include "com_sun_webkit_dom_JSObject.h"
>>>  ?????? |????????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> compilation terminated.
>>>
>>> That (generated) file seems to be at:
>>> ./modules/javafx.web/modules/javafx.web/build/gensrc/headers/javafx.web/
>>> com_sun_webkit_dom_JSObject.h
>>>
>>> But I can't figure out what is supposed to add that include path to the build.
>>>
>>> We are running cmake by hand with:
>>>
>>> /usr/bin/cmake -S ./modules/javafx.web/src/main/native -B redhat-linux-build
>>> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
>>> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
>>> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
>>> -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr
>>> -DCMAKE_INSTALL_FULL_SBINDIR:PATH=/usr/bin -DCMAKE_INSTALL_SBINDIR:PATH=bin
>>> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
>>> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
>>> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DDEVELOPER_MODE=ON
>>> -DPORT=Java -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=x86_64
>>> -DENABLE_TOOLS=1 -DJAVAFX_RELEASE_VERSION=25
>>>
>>> You can see a full build.log here:
>>> https://kojipkgs.fedoraproject.org//work/tasks/9897/138119897/build.log
>>>
>>> Any help would be greatly appreciated.
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kizune at openjdk.org  Mon Oct 13 18:44:35 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 13 Oct 2025 18:44:35 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 10 Oct 2025 21:11:50 GMT, Andy Goryachev  wrote:

> > a weird regression
> 
> any comments?

I was testing it and so far i can see that regression but i do not fully understand the reason behind it. Also this test behaves strangely with the useSystemMenuBar property toggle - when the "No Custom Menus" selected and the "use system menu bar" options checked the menu "No Custom Menus" is in the system menu bar but if i select anything else the items appear in the test frame. I have pulled changes from the master though.

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3398656878

From angorya at openjdk.org  Mon Oct 13 18:50:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 18:50:21 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 18:42:18 GMT, Alexander Zuev  wrote:

> i can see that regression but i do not fully understand the reason behind it

Is there enough value in this PR to treat the regression as a separate issue, or should we fix it in this PR?  

I am not sure that this is a rare corner case, since it happens when selecting a menu with an accessibility shortcut.  Maybe the fix is for the skin to consume that specific key event?

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3398672315

From kizune at openjdk.org  Mon Oct 13 19:15:32 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 13 Oct 2025 19:15:32 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 18:47:47 GMT, Andy Goryachev  wrote:

> > i can see that regression but i do not fully understand the reason behind it
> 
> Is there enough value in this PR to treat the regression as a separate issue, or should we fix it in this PR?
> 
> I am not sure that this is a rare corner case, since it happens when selecting a menu with an accessibility shortcut. Maybe the fix is for the skin to consume that specific key event?

Well i can trigger the same behavior without the new code with MonkeyTester - so it is not a regression. But i have to understand the reason of why it happens because i think - it is the same reason behind me not able to implement the editable text component accessibility - the fact that we are forwarding events to wrong or multiple nodes when accessibility is involved. So it deserves a separate bug and it deserves a lot of attention.

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3398738437

From jvos at openjdk.org  Mon Oct 13 19:38:54 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Oct 2025 19:38:54 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 12:28:42 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE | AFTER |
>> | - | - | - |
>> | Init | 0ms |0 ms |
>> | Init | 0ms | 0 ms |
>> | Init | 251 ms | 246 ms |
>> | Init | 47 ms | 50 ms |
>> | Init | 24 ms | 5 ms |
>> | Refresh Nr. 1 | 238 ms | 51 ms -> 0ms |
>> | Refresh Nr. 2 | 282 ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 176 ms | 36 ms -> 0ms |
>> | Refresh Nr. 4 | 151 ms | 39 ms -> 0ms |
>> | Refresh Nr. 5 | 156 ms | 34 ms -> 0ms |
>> 
>> 
>> 
>> 

>> Benchmark code
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.SimpleStringProperty;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.control.IndexedCell;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableRow;
>> import javafx.scene.control.TableView;
>> import javafx.scene.control.skin.TableViewSkin;
>> import javafx.scene.control.skin.VirtualFlow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.HBox;
>> import javafx.stage.Stage;
>> 
>> public class FXBug {
>> 
>>     public static void main(String[] args) {
>>         Application.launch(FxApp.class, args);
>>     }
>> 
>>  ...
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1830#pullrequestreview-3332804138

From angorya at openjdk.org  Mon Oct 13 19:57:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 19:57:22 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <_EDxOsEiPLXOc6sxl_ArOn3InXbAo1xgSqUqy41IrAc=.53b8b111-16c1-4d1c-91de-dd22b02d0dbb@github.com>

On Mon, 13 Oct 2025 19:13:10 GMT, Alexander Zuev  wrote:

> Well i can trigger the same behavior without the new code with MonkeyTester

Created a follow-up ticket: https://bugs.openjdk.org/browse/JDK-8369733
Could you add a comment with the steps to reproduce please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3398875834

From angorya at openjdk.org  Mon Oct 13 20:01:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 13 Oct 2025 20:01:34 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 10 Oct 2025 20:08:38 GMT, Alexander Zuev  wrote:

>> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.
>
> Alexander Zuev 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 nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8368972
>  - Merge pull request #22 from openjdk/master
>    
>    Merge
>  - Cover the case when menu item has children but it does not respond to the accessibilityValue selector;
>  - Caching children list;
>    Use nil instead of NULL;
>  - Restore CHECK_MENU_ITEM binding
>  - Fixing wrong copyright year
>  - Fixing the assignment;
>    Fixing the top level manu titles;
>  - Fixed typo
>  - 8368972: Create implementation of menu bar accessibility component
>    
>    Create a menu bar component accessibility peer and wire it to the component

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1927#pullrequestreview-3332899814

From kevin.rushforth at oracle.com  Mon Oct 13 20:34:28 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Oct 2025 13:34:28 -0700
Subject: Result: New OpenJFX Committer: Ziad El Midaoui
Message-ID: <3ac6807b-de25-4bd8-ae7a-05aca09dac6a@oracle.com>

Voting for Ziad El Midaoui [1] to OpenJFX Committer [2] is now closed.

Yes: 9
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#zelmidaoui

[2] 
https://mail.openjdk.org/pipermail/openjfx-dev/2025-September/056497.html


From kizune at openjdk.org  Mon Oct 13 21:35:22 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 13 Oct 2025 21:35:22 GMT
Subject: RFR: 8368972: Create implementation of menu bar accessibility
 component [v4]
In-Reply-To: <_EDxOsEiPLXOc6sxl_ArOn3InXbAo1xgSqUqy41IrAc=.53b8b111-16c1-4d1c-91de-dd22b02d0dbb@github.com>
References: 
 
 
 
 
 
 
 <_EDxOsEiPLXOc6sxl_ArOn3InXbAo1xgSqUqy41IrAc=.53b8b111-16c1-4d1c-91de-dd22b02d0dbb@github.com>
Message-ID: <8fbkLryPn2O3L5IF1K1PKxC1LIXmRwfRQ99itTsaWwE=.46d39083-7092-4b04-9ae3-6ebf1128f284@github.com>

On Mon, 13 Oct 2025 19:54:32 GMT, Andy Goryachev  wrote:

> > Well i can trigger the same behavior without the new code with MonkeyTester
> 
> Created a follow-up ticket: https://bugs.openjdk.org/browse/JDK-8369733 Could you add a comment with the steps to reproduce please?

Added step by step instruction on how to reproduce the same problem with the current nightly build of JavaFX.

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

PR Comment: https://git.openjdk.org/jfx/pull/1927#issuecomment-3399130716

From kizune at openjdk.org  Mon Oct 13 21:54:23 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 13 Oct 2025 21:54:23 GMT
Subject: Integrated: 8368972: Create implementation of menu bar accessibility
 component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 3 Oct 2025 20:49:21 GMT, Alexander Zuev  wrote:

> Create the accessibility peer for menu bar component also fix the problem when with the voiceover is on the -F10 is pressed the name of the selected menu is not announced.

This pull request has now been integrated.

Changeset: 89d6a7eb
Author:    Alexander Zuev 
URL:       https://git.openjdk.org/jfx/commit/89d6a7ebfd3dfcc6510139a9fe7f5f7efeca850a
Stats:     60 lines in 4 files changed: 55 ins; 2 del; 3 mod

8368972: Create implementation of menu bar accessibility component

Reviewed-by: angorya, arapte

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

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

From orion at nwra.com  Mon Oct 13 23:46:12 2025
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 13 Oct 2025 17:46:12 -0600
Subject: [External] : Re: Trouble compiling openjfx webkit on Fedora Linux
In-Reply-To: <12828462-c05a-45c1-b67e-5be23d35e92a@oracle.com>
References: 
 
 <3934d63b-be80-4b37-9d25-8fcada2568d7@nwra.com>
 <12828462-c05a-45c1-b67e-5be23d35e92a@oracle.com>
Message-ID: <456a525b-763e-4837-9ceb-c63f685cf984@nwra.com>

On 10/13/25 12:26, Kevin Rushforth wrote:
> 
> 
> On 10/13/2025 10:42 AM, Orion Poplawski wrote:
>> On 10/13/25 11:28, Kevin Rushforth wrote:
>>> This looks like it might be related to moving jdk.jsobject out of the JDK to
>>> be distributed with JavaFX that I did starting in JDK 24 / JavaFX 24.
>> I don't think so as I see it in old versions as well.
> 
> Yes, I looked more closely at your failure, and you are right. It isn't 
> related.
> 
>>> A few questions:
>>>
>>> 1. What JDK are you using to build? Does it have JavaFX modules in it?
>> OpenJDK 25.  It does not have JavaFX modules - that is what this package
>> provides.>
> 
> OK.
> 
>>> 2. What OS are you using to build? What version of GCC?
>> Fedora Rawhide.  GCC 15.2.1
> 
> You may or may not run into any GCC 15 failures (we had several with GCC 
> 14, which are now all fixed). If you do, feel free to let us know.
> 
>>> 3. What tag or branch in the jfx (or is it jfx25u) repo are you using?
>> I've tried with a couple different ones:
>>
>> jfx17u-17.0.13-0
>> jfx21u-21.0.9+1
>> jfx25u-25+29
> 
> OK.
> 
>>> 4. What is the gradle command line you used to build?
>> Again, we're not using gradle because it is not packaged for Fedora and we
>> must build using packaged tools.>
> 
> You are in uncharted waters then. How are you building the class files 
> and the modules if you don't run "gradle"? It isn't as simple as running 
> "javac". I don't have the time to help you debug your environment, but I 
> would recommend looking at what the gradle build does when it builds the 
> class files. Specifically, the header files that are missing and causing 
> your build failure are generated as part of building the Java classes 
> for the javafx.web module (which must be built before the native code 
> can be built).
> 
> I didn't spot anything amiss in the cmake output, so it might be that 
> once you run javac to build the classes and header files you'll be able 
> to proceed.
> 
> Good luck.
> 
> -- Kevin

Are there any detailed webkit build logs out there that I could use as a 
reference?


-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

From orion at nwra.com  Tue Oct 14 00:22:21 2025
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 13 Oct 2025 18:22:21 -0600
Subject: Building openjfx
Message-ID: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>

So I'm stepping back to simply try building openjfx with gradlew but I get:

$ sh gradlew --info build
Initialized native services in: /home/orion/.gradle/native
Initialized jansi services in: /home/orion/.gradle/native
The client will now receive all logging from the daemon (pid: 253483). 
The daemon log file: /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
Starting 2nd build in daemon [uptime: 2 mins 22.763 secs, performance: 
97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage: 9% of 
384 MiB]
Using 6 worker leases.
Now considering [/home/orion/openjfx-25/jfx25u-25-29] as hierarchies to 
watch
Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc, 
/home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
Watching the file system is configured to be enabled if available
File system watching is active
Starting Build
Caching disabled for Groovy DSL script compilation (settings) because:
   Build cache is disabled
   Not worth caching.
Compiling settings file 
'/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using 
BuildScriptTransformer.

FAILURE: Build failed with an exception.

* What went wrong:
BUG! exception in phase 'semantic analysis' in source unit 
'_BuildScript_' Unsupported class file major version 69
 > Unsupported class file major version 69

* Try:
 > Run with --stacktrace option to get the stack trace.
 > Run with --debug option to get more log output.
 > Run with --scan to get full insights.
 > Get more help at https://help.gradle.org.

BUILD FAILED in 466ms

$ java --version
openjdk 25 2025-09-16
OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36, mixed 
mode, sharing)

What am I doing wrong?

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From jdv at openjdk.org  Tue Oct 14 04:24:24 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 14 Oct 2025 04:24:24 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 14:03:15 GMT, John Hendrikx  wrote:

>> Just to be sure, the CSR required here is for the newly added constructors?  The documentation changes on the existing constructors are only clarifications, no functionality was changed.
>
>> @hjohn The last piece is the CSR. I'll review it once it is ready.
> 
> @kevinrushforth Sorry for the delay, I created the CSR now and moved it to proposed.

@hjohn Since this PR is ready, please delegate the integration of this PR using "/integrate delegate" command.(https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate).

This will enable me to check-in this PR and closed-side whitebox test change at same time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3400056765

From notzed at gmail.com  Tue Oct 14 06:40:44 2025
From: notzed at gmail.com (Michael Zucchi)
Date: Tue, 14 Oct 2025 17:10:44 +1030
Subject: Building openjfx
In-Reply-To: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
References: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
Message-ID: 


Orion,

I believe you have to use openjdk 24 as gradle 8.14.x doesn't support 25.

I also had to add -Dorg.gradle.java.home=/correct/path as it insisted on 
using the wrong version of many installed locally.

Otherwise I found it pretty trivial to build, good luck.

 ?Z


On 14/10/25 10:52, Orion Poplawski wrote:
> So I'm stepping back to simply try building openjfx with gradlew but I 
> get:
>
> $ sh gradlew --info build
> Initialized native services in: /home/orion/.gradle/native
> Initialized jansi services in: /home/orion/.gradle/native
> The client will now receive all logging from the daemon (pid: 253483). 
> The daemon log file: 
> /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
> Starting 2nd build in daemon [uptime: 2 mins 22.763 secs, performance: 
> 97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage: 9% of 
> 384 MiB]
> Using 6 worker leases.
> Now considering [/home/orion/openjfx-25/jfx25u-25-29] as hierarchies 
> to watch
> Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc, 
> /home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
> Watching the file system is configured to be enabled if available
> File system watching is active
> Starting Build
> Caching disabled for Groovy DSL script compilation (settings) because:
> ? Build cache is disabled
> ? Not worth caching.
> Compiling settings file 
> '/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using 
> BuildScriptTransformer.
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> BUG! exception in phase 'semantic analysis' in source unit 
> '_BuildScript_' Unsupported class file major version 69
> > Unsupported class file major version 69
>
> * Try:
> > Run with --stacktrace option to get the stack trace.
> > Run with --debug option to get more log output.
> > Run with --scan to get full insights.
> > Get more help at https://help.gradle.org.
>
> BUILD FAILED in 466ms
>
> $ java --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
> OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36, mixed 
> mode, sharing)
>
> What am I doing wrong?
>


From jpereda at openjdk.org  Tue Oct 14 08:24:36 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 14 Oct 2025 08:24:36 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v4]
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: <1tyW6zZKHmvzwQbLpMwufnR0_LGWTr1bI_e8s3SvXB0=.8a37988a-9127-4a91-a5c7-ef58830ca6c6@github.com>

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Process feedback

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1934/files
  - new: https://git.openjdk.org/jfx/pull/1934/files/47a450a6..484f5cbd

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

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

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

From jpereda at openjdk.org  Tue Oct 14 08:24:37 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 14 Oct 2025 08:24:37 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v4]
In-Reply-To: <6KI8STxuwzllH-r2PAvdNt45ygJQI1cjTIKeSjJiM14=.842c3ff4-751b-431e-b079-b23d2606e3a8@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 
 
 
 
 
 <6KI8STxuwzllH-r2PAvdNt45ygJQI1cjTIKeSjJiM14=.842c3ff4-751b-431e-b079-b23d2606e3a8@github.com>
Message-ID: 

On Mon, 13 Oct 2025 18:22:07 GMT, Kevin Rushforth  wrote:

>> As I said in my previous comment, I don't see this as a showstopper for this PR, but since it might help in general, I keep thinking about approaches to remove the sleep.
>> Wouldn't it be an option here to obtain the JavaFX Application Thread after the `assertTrue(Platform.isFxApplicationThread());` and assign it to e.g. `Thread fxThread` so that instead of the `Util.sleep` we can do `fxThread.join(10)` ? (I might be missing something though)
>
> Yes, something like what you describe might work in this case.
> 
> As for the more general problem, which goes well beyond this PR, there are many places in our tests where we do need sleeps. They fall into two cases
> 
> 1. Lack of a feature that provides a deterministic way to know when something has occurred. Implementing the missing functionality could allow us to replace sleeps with something more deterministic.
> 2. Inherent limitations where there cannot be a deterministic way to know when something has occurred.
> 
> Many, if not most, of the instances of 1 could be addressed with an implementation of `Robot::waitForIdle`. It's a long-standing feature request. It's not rocket science to implement, but isn't trivial either.
> 
> Most of the instances of 2 are due to either A) platform delay in realizing certain window system operations (show/hide/minimize/maximize/to-front/etc); or B) inherent GC non-determinism.

I've replaced `Util.sleep(10)` with `fxThread.join(10)`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2428320801

From arapte at openjdk.org  Tue Oct 14 08:25:59 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 14 Oct 2025 08:25:59 GMT
Subject: Integrated: 8360586: JavaFX build uses deprecated features that will
 be removed in gradle 9
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 Sep 2025 21:08:50 GMT, Ambarish Rapte  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.

This pull request has now been integrated.

Changeset: c61e2697
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/c61e269703952318d3437d07a572049200326ff5
Stats:     238 lines in 13 files changed: 120 ins; 1 del; 117 mod

8360586: JavaFX build uses deprecated features that will be removed in gradle 9

Reviewed-by: kcr, sykora

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

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

From jhendrikx at openjdk.org  Tue Oct 14 08:50:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 14 Oct 2025 08:50:40 GMT
Subject: Integrated: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Aug 2025 09:35:23 GMT, John Hendrikx  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

This pull request has now been integrated.

Changeset: 4f4540fb
Author:    John Hendrikx 
Committer: Jayathirth D V 
URL:       https://git.openjdk.org/jfx/commit/4f4540fb8620fa5f695e4086a45f9c8b288bf7d9
Stats:     304 lines in 11 files changed: 180 ins; 72 del; 52 mod

8361286: Allow enabling of background loading for images loaded from an InputStream

Reviewed-by: angorya, jdv, kcr

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

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

From nlisker at openjdk.org  Tue Oct 14 08:54:50 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 14 Oct 2025 08:54:50 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 13:57:19 GMT, Nir Lisker  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:
> 
>   Review comments

Thanks for the reviews everyone.

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

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

From nlisker at openjdk.org  Tue Oct 14 08:54:50 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 14 Oct 2025 08:54:50 GMT
Subject: Integrated: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: 
References: 
Message-ID: 

On Sat, 16 Aug 2025 20:44:28 GMT, Nir Lisker  wrote:

> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

This pull request has now been integrated.

Changeset: 2026a24a
Author:    Nir Lisker 
URL:       https://git.openjdk.org/jfx/commit/2026a24a795df7c508e816e664199530b56fd0c8
Stats:     105 lines in 5 files changed: 97 ins; 3 del; 5 mod

8365635: Add MOUSE_DRAG_DONE event type

Reviewed-by: angorya, kcr, mstrauss, jhendrikx

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

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

From jvos at openjdk.org  Tue Oct 14 08:55:52 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 14 Oct 2025 08:55:52 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
 
 
 
Message-ID: 

On Mon, 13 Oct 2025 17:10:20 GMT, Andy Goryachev  wrote:

> I know you do - the links were added for sake of others :-)

very kind ;)

> The answer to your question is - I don't know. If one can guarantee that there is only one thread accessing it, we may need to add a comment (though things might change in the future, and no one reads comments elsewhere in the code). And if not, then some form of synchronization is mandatory.

I ran all system tests to see when/how the active field was read/modified and on which thread. All operations did happen on the main/eventThread, hence single-threaded. Since all of this is about processing events for the eventThread, this makes sense. But to make sure, I did the following research:

There are 3 places in NestedRunnableProcessor where the active field is used (read or write)

`Object newRunLoop()`

The first time this is invoked is when the `HeadlessApplication` starts, when `Application.run` is called. This creates a new Thread, which is the eventThread. The first thing this thread does is invoking `runLoop` (hence, it is executed on the eventThread).
Apart from the first time, this is invoked from `Application.enterNestedEventLoop`. which clearly states in its javadoc that the method may only be invoked on the main (event handling) thread, and it even does a `checkEventThread()` for this.

`void leaveCurrentLoop()`

This is invoked from `Application.leaveNestedEventLoop`, which has the same docs + check as `enterNestedEventLoop`

`void stopProcessing()`

This is invoked from Application.terminate, which starts with a `checkEventThread`

In summary, all operations in the NestedRunnableProcessor or controlled/gated by the com.sun.glass.ui.Application which makes sure that all access is guarded by `checkEventThread`

> I prefer not to think though, and make sure we don't plant booby traps in the code.
I don't think I follow this approach. There are many concerns about "JavaFX being slow", so if we can avoid it, I think we should. That doesn't give green light to plant booby traps of course ;)
> 

> BTW, what is the cost of volatile? 0.1 ns? ;-)

I'm not an expert, but I believe it is more than 1 ns on "typical desktop systems". Since this is evaluated on every invocation of a Runnable on the AppThread (hence all pulses), plus on every Runnable executed via e.g. Platform.runLater(), this is something that can be invoked very often.

If there was even a single cornercase that we could not rule out, or document as "you're on your own here", I would absolutely agree to make it volatile. But as far as I see, there is no legal case where issues can occur that would have been prevented by adding volatile in this case.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2428410682

From nlisker at gmail.com  Tue Oct 14 09:24:06 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 14 Oct 2025 12:24:06 +0300
Subject: Building openjfx
In-Reply-To: 
References: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
 
Message-ID: 

Gradle tells you how to find out what you're doing wrong:

* Try:
>  > Run with --stacktrace option to get the stack trace.
>  > Run with --debug option to get more log output.
>  > Run with --scan to get full insights.
>  > Get more help at https://help.gradle.org.


In any case, the error message is straightforward: "Unsupported class file
major version 69" means that the corresponding Java version (25) is
unsupported in the Gradle version you're using. You can create a file
inside your gradle home directory (.gradle) called "gradle.properties" and
set the org.gradle.java.home property to the path of a previous Java
version if you don't want to change your global env var.

On Tue, Oct 14, 2025 at 9:41?AM Michael Zucchi  wrote:

>
> Orion,
>
> I believe you have to use openjdk 24 as gradle 8.14.x doesn't support 25.
>
> I also had to add -Dorg.gradle.java.home=/correct/path as it insisted on
> using the wrong version of many installed locally.
>
> Otherwise I found it pretty trivial to build, good luck.
>
>   Z
>
>
> On 14/10/25 10:52, Orion Poplawski wrote:
> > So I'm stepping back to simply try building openjfx with gradlew but I
> > get:
> >
> > $ sh gradlew --info build
> > Initialized native services in: /home/orion/.gradle/native
> > Initialized jansi services in: /home/orion/.gradle/native
> > The client will now receive all logging from the daemon (pid: 253483).
> > The daemon log file:
> > /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
> > Starting 2nd build in daemon [uptime: 2 mins 22.763 secs, performance:
> > 97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage: 9% of
> > 384 MiB]
> > Using 6 worker leases.
> > Now considering [/home/orion/openjfx-25/jfx25u-25-29] as hierarchies
> > to watch
> > Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc,
> > /home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
> > Watching the file system is configured to be enabled if available
> > File system watching is active
> > Starting Build
> > Caching disabled for Groovy DSL script compilation (settings) because:
> >   Build cache is disabled
> >   Not worth caching.
> > Compiling settings file
> > '/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using
> > BuildScriptTransformer.
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > BUG! exception in phase 'semantic analysis' in source unit
> > '_BuildScript_' Unsupported class file major version 69
> > > Unsupported class file major version 69
> >
> > * Try:
> > > Run with --stacktrace option to get the stack trace.
> > > Run with --debug option to get more log output.
> > > Run with --scan to get full insights.
> > > Get more help at https://help.gradle.org.
> >
> > BUILD FAILED in 466ms
> >
> > $ java --version
> > openjdk 25 2025-09-16
> > OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
> > OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36, mixed
> > mode, sharing)
> >
> > What am I doing wrong?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin.rushforth at oracle.com  Tue Oct 14 15:30:27 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Oct 2025 08:30:27 -0700
Subject: Building openjfx
In-Reply-To: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
References: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
Message-ID: <862c9832-c921-401c-b387-e138bd8fb92b@oracle.com>

Ah yes, you are running into one of the charming issues with using 
gradle: namely, gradle is slow in supporting the latest JDKs.

The easiest way is to use JDK 24.x (e.g., 24.0.2) to both run gradle and 
build JavaFX. This is what we do.

If you need to use JDK 25 to build, you will need two JDKs: one to run 
gradle (JDK 24 or earlier) and another to use for building. Point 
JAVA_HOME to the JDK used to launch gradle and put it in your PATH. 
Point JDK_HOME to the JDK 25 that you will use to build JavaFX.

-- Kevin



On 10/13/2025 5:22 PM, Orion Poplawski wrote:
> So I'm stepping back to simply try building openjfx with gradlew but I 
> get:
>
> $ sh gradlew --info build
> Initialized native services in: /home/orion/.gradle/native
> Initialized jansi services in: /home/orion/.gradle/native
> The client will now receive all logging from the daemon (pid: 253483). 
> The daemon log file: 
> /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
> Starting 2nd build in daemon [uptime: 2 mins 22.763 secs, performance: 
> 97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage: 9% of 
> 384 MiB]
> Using 6 worker leases.
> Now considering [/home/orion/openjfx-25/jfx25u-25-29] as hierarchies 
> to watch
> Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc, 
> /home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
> Watching the file system is configured to be enabled if available
> File system watching is active
> Starting Build
> Caching disabled for Groovy DSL script compilation (settings) because:
> ? Build cache is disabled
> ? Not worth caching.
> Compiling settings file 
> '/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using 
> BuildScriptTransformer.
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> BUG! exception in phase 'semantic analysis' in source unit 
> '_BuildScript_' Unsupported class file major version 69
> > Unsupported class file major version 69
>
> * Try:
> > Run with --stacktrace option to get the stack trace.
> > Run with --debug option to get more log output.
> > Run with --scan to get full insights.
> > Get more help at https://help.gradle.org.
>
> BUILD FAILED in 466ms
>
> $ java --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
> OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36, mixed 
> mode, sharing)
>
> What am I doing wrong?
>


From angorya at openjdk.org  Tue Oct 14 15:34:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 14 Oct 2025 15:34:16 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v4]
In-Reply-To: <1tyW6zZKHmvzwQbLpMwufnR0_LGWTr1bI_e8s3SvXB0=.8a37988a-9127-4a91-a5c7-ef58830ca6c6@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 <1tyW6zZKHmvzwQbLpMwufnR0_LGWTr1bI_e8s3SvXB0=.8a37988a-9127-4a91-a5c7-ef58830ca6c6@github.com>
Message-ID: 

On Tue, 14 Oct 2025 08:24:36 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback

Marked as reviewed by angorya (Reviewer).

tests/system/src/test/java/test/com/sun/glass/ui/headless/HeadlessApplication2Test.java line 77:

> 75:             fxThread.join(10);
> 76:         }  catch (InterruptedException e) {
> 77:             fail.set(true);

`Assertions.fail()` might work too

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

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3336283309
PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2429616805

From angorya at openjdk.org  Tue Oct 14 15:34:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 14 Oct 2025 15:34:17 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
 
 
 
 
Message-ID: <5tU1UgOitGqKdJ5tdtfP2Pg7jdZhuM_r2he_DUEt2po=.2a162041-76fb-4e75-a44d-7ea82b2469b0@github.com>

On Tue, 14 Oct 2025 08:53:11 GMT, Johan Vos  wrote:

>> I know you do - the links were added for sake of others :-)
>> 
>> The answer to your question is - I don't know.  If one can guarantee that there is only one thread accessing it, we may need to add a comment (though things might change in the future, and no one reads comments elsewhere in the code).  And if not, then some form of synchronization is mandatory.
>> 
>> I prefer not to think though, and make sure we don't plant booby traps in the code.
>> 
>> BTW, what is the cost of volatile?  0.1 ns?  ;-)
>
>> I know you do - the links were added for sake of others :-)
> 
> very kind ;)
> 
>> The answer to your question is - I don't know. If one can guarantee that there is only one thread accessing it, we may need to add a comment (though things might change in the future, and no one reads comments elsewhere in the code). And if not, then some form of synchronization is mandatory.
> 
> I ran all system tests to see when/how the active field was read/modified and on which thread. All operations did happen on the main/eventThread, hence single-threaded. Since all of this is about processing events for the eventThread, this makes sense. But to make sure, I did the following research:
> 
> There are 3 places in NestedRunnableProcessor where the active field is used (read or write)
> 
> `Object newRunLoop()`
> 
> The first time this is invoked is when the `HeadlessApplication` starts, when `Application.run` is called. This creates a new Thread, which is the eventThread. The first thing this thread does is invoking `runLoop` (hence, it is executed on the eventThread).
> Apart from the first time, this is invoked from `Application.enterNestedEventLoop`. which clearly states in its javadoc that the method may only be invoked on the main (event handling) thread, and it even does a `checkEventThread()` for this.
> 
> `void leaveCurrentLoop()`
> 
> This is invoked from `Application.leaveNestedEventLoop`, which has the same docs + check as `enterNestedEventLoop`
> 
> `void stopProcessing()`
> 
> This is invoked from Application.terminate, which starts with a `checkEventThread`
> 
> In summary, all operations in the NestedRunnableProcessor or controlled/gated by the com.sun.glass.ui.Application which makes sure that all access is guarded by `checkEventThread`
> 
>> I prefer not to think though, and make sure we don't plant booby traps in the code.
> I don't think I follow this approach. There are many concerns about "JavaFX being slow", so if we can avoid it, I think we should. That doesn't give green light to plant booby traps of course ;)
>> 
> 
>> BTW, what is the cost of volatile? 0.1 ns? ;-)
> 
> I'm not an expert, but I believe it is more than 1 ns on "typical desktop systems". Since this is evaluated on every invocation of a Runnable on the AppThread (hence all pulses), plus on every Runnable executed via e.g. Platform.runLater(), this is something that can be invoked very often.
> 
> If there was even a single cornercase that we could not rule out, or document as "you're on your own here", I would absolutely agree to make it ...

Thank you for the analysis, very helpful!  I would like to ask for a comment to be added, explaining the design.  The main reason is I've seen too many times when the code was broken because the original assumptions were no longer valid, long after the knowledgeable people have left.  At least the comment might help future reviewers.  (I'll re-approve if you decide to add the comment).

BTW, you are right - according to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ the overhead of `volatile` might be a few nanoseconds on modern systems.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2429611866

From kevin.rushforth at oracle.com  Tue Oct 14 15:43:29 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Oct 2025 08:43:29 -0700
Subject: Building openjfx
In-Reply-To: 
References: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
 
 
Message-ID: 

I hadn't tried setting `org.gradle.java.home`, but if that works, it 
might be easier than our current recipe.

-- Kevin


On 10/14/2025 2:24 AM, Nir Lisker wrote:
> Gradle tells you how to find out what you're doing wrong:
>
>     * Try:
>     ?> Run with --stacktrace option to get the stack trace.
>     ?> Run with --debug option to get more log output.
>     ?> Run with --scan to get full insights.
>     ?> Get more help at https://help.gradle.org.
>
>
> In any case, the error message is straightforward: "Unsupported class 
> file major version 69" means that the corresponding Java version (25) 
> is unsupported in the Gradle version you're?using. You can create a 
> file inside your gradle home directory (.gradle) called 
> "gradle.properties" and set the?org.gradle.java.home property to the 
> path of a previous Java version if you don't want to change your 
> global env var.
>
> On Tue, Oct 14, 2025 at 9:41?AM Michael Zucchi  wrote:
>
>
>     Orion,
>
>     I believe you have to use openjdk 24 as gradle 8.14.x doesn't
>     support 25.
>
>     I also had to add -Dorg.gradle.java.home=/correct/path as it
>     insisted on
>     using the wrong version of many installed locally.
>
>     Otherwise I found it pretty trivial to build, good luck.
>
>     ??Z
>
>
>     On 14/10/25 10:52, Orion Poplawski wrote:
>     > So I'm stepping back to simply try building openjfx with gradlew
>     but I
>     > get:
>     >
>     > $ sh gradlew --info build
>     > Initialized native services in: /home/orion/.gradle/native
>     > Initialized jansi services in: /home/orion/.gradle/native
>     > The client will now receive all logging from the daemon (pid:
>     253483).
>     > The daemon log file:
>     > /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
>     > Starting 2nd build in daemon [uptime: 2 mins 22.763 secs,
>     performance:
>     > 97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage:
>     9% of
>     > 384 MiB]
>     > Using 6 worker leases.
>     > Now considering [/home/orion/openjfx-25/jfx25u-25-29] as
>     hierarchies
>     > to watch
>     > Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc,
>     > /home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
>     > Watching the file system is configured to be enabled if available
>     > File system watching is active
>     > Starting Build
>     > Caching disabled for Groovy DSL script compilation (settings)
>     because:
>     > ? Build cache is disabled
>     > ? Not worth caching.
>     > Compiling settings file
>     > '/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using
>     > BuildScriptTransformer.
>     >
>     > FAILURE: Build failed with an exception.
>     >
>     > * What went wrong:
>     > BUG! exception in phase 'semantic analysis' in source unit
>     > '_BuildScript_' Unsupported class file major version 69
>     > > Unsupported class file major version 69
>     >
>     > * Try:
>     > > Run with --stacktrace option to get the stack trace.
>     > > Run with --debug option to get more log output.
>     > > Run with --scan to get full insights.
>     > > Get more help at https://help.gradle.org.
>     >
>     > BUILD FAILED in 466ms
>     >
>     > $ java --version
>     > openjdk 25 2025-09-16
>     > OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
>     > OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36,
>     mixed
>     > mode, sharing)
>     >
>     > What am I doing wrong?
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Tue Oct 14 15:53:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Oct 2025 15:53:19 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v4]
In-Reply-To: <1tyW6zZKHmvzwQbLpMwufnR0_LGWTr1bI_e8s3SvXB0=.8a37988a-9127-4a91-a5c7-ef58830ca6c6@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 <1tyW6zZKHmvzwQbLpMwufnR0_LGWTr1bI_e8s3SvXB0=.8a37988a-9127-4a91-a5c7-ef58830ca6c6@github.com>
Message-ID: <2JNs45TUR17moOdTvo6LpoBQhsUuIdIHc3D6icKbtAE=.f4ca91e9-4fbd-45b7-9493-794fe2c1f31c@github.com>

On Tue, 14 Oct 2025 08:24:36 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3336366489

From kcr at openjdk.org  Tue Oct 14 15:53:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Oct 2025 15:53:20 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v3]
In-Reply-To: <5tU1UgOitGqKdJ5tdtfP2Pg7jdZhuM_r2he_DUEt2po=.2a162041-76fb-4e75-a44d-7ea82b2469b0@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
 <5DZmfqAxyCs5AsC-A_Oid-EPIzeHN1MbGlx2W2msrtU=.05445c75-6eb0-4558-bf7f-86d7ccdec34f@github.com>
 
 
 
 
 
 
 <5tU1UgOitGqKdJ5tdtfP2Pg7jdZhuM_r2he_DUEt2po=.2a162041-76fb-4e75-a44d-7ea82b2469b0@github.com>
Message-ID: 

On Tue, 14 Oct 2025 15:30:20 GMT, Andy Goryachev  wrote:

>>> I know you do - the links were added for sake of others :-)
>> 
>> very kind ;)
>> 
>>> The answer to your question is - I don't know. If one can guarantee that there is only one thread accessing it, we may need to add a comment (though things might change in the future, and no one reads comments elsewhere in the code). And if not, then some form of synchronization is mandatory.
>> 
>> I ran all system tests to see when/how the active field was read/modified and on which thread. All operations did happen on the main/eventThread, hence single-threaded. Since all of this is about processing events for the eventThread, this makes sense. But to make sure, I did the following research:
>> 
>> There are 3 places in NestedRunnableProcessor where the active field is used (read or write)
>> 
>> `Object newRunLoop()`
>> 
>> The first time this is invoked is when the `HeadlessApplication` starts, when `Application.run` is called. This creates a new Thread, which is the eventThread. The first thing this thread does is invoking `runLoop` (hence, it is executed on the eventThread).
>> Apart from the first time, this is invoked from `Application.enterNestedEventLoop`. which clearly states in its javadoc that the method may only be invoked on the main (event handling) thread, and it even does a `checkEventThread()` for this.
>> 
>> `void leaveCurrentLoop()`
>> 
>> This is invoked from `Application.leaveNestedEventLoop`, which has the same docs + check as `enterNestedEventLoop`
>> 
>> `void stopProcessing()`
>> 
>> This is invoked from Application.terminate, which starts with a `checkEventThread`
>> 
>> In summary, all operations in the NestedRunnableProcessor or controlled/gated by the com.sun.glass.ui.Application which makes sure that all access is guarded by `checkEventThread`
>> 
>>> I prefer not to think though, and make sure we don't plant booby traps in the code.
>> I don't think I follow this approach. There are many concerns about "JavaFX being slow", so if we can avoid it, I think we should. That doesn't give green light to plant booby traps of course ;)
>>> 
>> 
>>> BTW, what is the cost of volatile? 0.1 ns? ;-)
>> 
>> I'm not an expert, but I believe it is more than 1 ns on "typical desktop systems". Since this is evaluated on every invocation of a Runnable on the AppThread (hence all pulses), plus on every Runnable executed via e.g. Platform.runLater(), this is something that can be invoked very often.
>> 
>> If there was even a single cornercase that we could not rule out, or document as ...
>
> Thank you for the analysis, very helpful!  I would like to ask for a comment to be added, explaining the design.  The main reason is I've seen too many times when the code was broken because the original assumptions were no longer valid, long after the knowledgeable people have left.  At least the comment might help future reviewers.  (I'll re-approve if you decide to add the comment).
> 
> BTW, you are right - according to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ the overhead of `volatile` might be a few nanoseconds on modern systems.

Glass is single-threaded by design, except for those methods that may be called on any thread. So I don't think a detailed comment is needed. A brief comment saying "this is only accessed on the JavaFX application thread (or event thread) might be helpful.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2429669667

From jpereda at openjdk.org  Tue Oct 14 16:11:59 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 14 Oct 2025 16:11:59 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v5]
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: 

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Process feedback

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1934/files
  - new: https://git.openjdk.org/jfx/pull/1934/files/484f5cbd..9fa25f00

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

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

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

From angorya at openjdk.org  Tue Oct 14 16:12:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 14 Oct 2025 16:12:00 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v5]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: 

On Tue, 14 Oct 2025 16:08:50 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3336450439

From kcr at openjdk.org  Tue Oct 14 16:24:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Oct 2025 16:24:06 GMT
Subject: RFR: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform [v5]
In-Reply-To: 
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
 
Message-ID: 

On Tue, 14 Oct 2025 16:11:59 GMT, Jose Pereda  wrote:

>> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process feedback

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1934#pullrequestreview-3336505651

From mstrauss at openjdk.org  Tue Oct 14 16:40:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 14 Oct 2025 16:40:18 GMT
Subject: RFR: 8369836: Update HeaderBar API
Message-ID: 

The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.

With this in mind, there are two changes for the `HeaderBar` control:
1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.

With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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

Commit messages:
 - Update HeaderBar API

Changes: https://git.openjdk.org/jfx/pull/1936/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369836
  Stats: 212 lines in 3 files changed: 14 ins; 56 del; 142 mod
  Patch: https://git.openjdk.org/jfx/pull/1936.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1936/head:pull/1936

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

From jpereda at openjdk.org  Tue Oct 14 16:50:39 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 14 Oct 2025 16:50:39 GMT
Subject: Integrated: 8369306: Implement invokeAndWait and finishTerminating on
 headless platform
In-Reply-To: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
References: <77viLnHKnHfyy0aEgiMlcu-KJRqPcE6fJov2J4Qcu8Y=.489ab4e0-c77f-4ac0-9746-a94b8bc4f79f@github.com>
Message-ID: 

On Fri, 10 Oct 2025 09:25:39 GMT, Jose Pereda  wrote:

> This PR implements `invokeAndWait` and `finishTerminating` for the headless platform and includes two system tests, one for each, that fail before this PR, and pass after it.

This pull request has now been integrated.

Changeset: 38300ca6
Author:    Jose Pereda 
URL:       https://git.openjdk.org/jfx/commit/38300ca6c6c3483d35abec6f3fb2431402a26af0
Stats:     194 lines in 4 files changed: 193 ins; 0 del; 1 mod

8369306: Implement invokeAndWait and finishTerminating on headless platform

Reviewed-by: kcr, angorya, jvos

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

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

From andy.goryachev at oracle.com  Tue Oct 14 16:52:15 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 14 Oct 2025 16:52:15 +0000
Subject: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
Message-ID: 

Can you clarify what you mean by "aligning with" BorderPane?

Does it mean we are trying to propagate somewhat misleading terminology that was used by the BorderPane (setLeft() in RTL mode results in the added node on the right side, so it should really be named something like setLeading() instead of setLeft()).

Thanks,
-andy


From: openjfx-dev  on behalf of Michael Strau? 
Date: Tuesday, October 14, 2025 at 09:40
To: openjfx-dev at openjdk.org 
Subject: RFR: 8369836: Update HeaderBar API

The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.

With this in mind, there are two changes for the `HeaderBar` control:
1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.

With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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

Commit messages:
 - Update HeaderBar API

Changes: https://git.openjdk.org/jfx/pull/1936/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369836
  Stats: 212 lines in 3 files changed: 14 ins; 56 del; 142 mod
  Patch: https://git.openjdk.org/jfx/pull/1936.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1936/head:pull/1936

PR: https://git.openjdk.org/jfx/pull/1936
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From michaelstrau2 at gmail.com  Tue Oct 14 17:01:48 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 14 Oct 2025 19:01:48 +0200
Subject: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
 
Message-ID: 

Yes, exactly. "Left" and "right" is used in several places in JavaFX
(BorderPane, AnchorPane, Insets) to effectively mean "leading" and
"trailing".
HeaderBar is different, because it uses "left", "right", as well as
"leading" and "trailing" with a different definition than the other
controls (leading and trailing are RTL adjusted, while left and right
are not).
My proposal is to just accept that "left" and "right" are JavaFX
terminology for RTL-adjusted leading and trailing areas.


On Tue, Oct 14, 2025 at 6:52?PM Andy Goryachev
 wrote:
>
> Can you clarify what you mean by "aligning with" BorderPane?
>
> Does it mean we are trying to propagate somewhat misleading terminology that was used by the BorderPane (setLeft() in RTL mode results in the added node on the right side, so it should really be named something like setLeading() instead of setLeft()).
>
> Thanks,
> -andy

From jvos at openjdk.org  Tue Oct 14 17:07:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 14 Oct 2025 17:07:19 GMT
Subject: [jfx25u] RFR: 8369140: GHA: Update macOS / x64 build to use
 macos-15-intel runner
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 00:21:15 GMT, Kevin Rushforth  wrote:

> Clean backport of GHA fix to jfx25u.

Good that this is documented. It should be clear that we use GhA for some testing, but we don't use it for doing production builds because we don't control the version of the tools (e.g. xcode 15.4 on macOs 15)

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx25u/pull/23#pullrequestreview-3336675816

From andy.goryachev at oracle.com  Tue Oct 14 17:08:21 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 14 Oct 2025 17:08:21 +0000
Subject: [External] : Re: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
 
 
Message-ID: 

I would rather clarify the incorrect labels in the existing components.  We obviously cannot change setLeft() - perhaps we should add explanation to the corresponding javadoc explaining RTL behavior.  I would like to avoid making the same mistake going forward.

-andy

From: Michael Strau? 
Date: Tuesday, October 14, 2025 at 10:02
To: Andy Goryachev 
Cc: Michael Strau? , openjfx-dev at openjdk.org 
Subject: [External] : Re: RFR: 8369836: Update HeaderBar API

Yes, exactly. "Left" and "right" is used in several places in JavaFX
(BorderPane, AnchorPane, Insets) to effectively mean "leading" and
"trailing".
HeaderBar is different, because it uses "left", "right", as well as
"leading" and "trailing" with a different definition than the other
controls (leading and trailing are RTL adjusted, while left and right
are not).
My proposal is to just accept that "left" and "right" are JavaFX
terminology for RTL-adjusted leading and trailing areas.


On Tue, Oct 14, 2025 at 6:52?PM Andy Goryachev
 wrote:
>
> Can you clarify what you mean by "aligning with" BorderPane?
>
> Does it mean we are trying to propagate somewhat misleading terminology that was used by the BorderPane (setLeft() in RTL mode results in the added node on the right side, so it should really be named something like setLeading() instead of setLeft()).
>
> Thanks,
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From michaelstrau2 at gmail.com  Tue Oct 14 17:23:01 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 14 Oct 2025 19:23:01 +0200
Subject: [External] : Re: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Considering that the "left" and "right" terminology is deeply
entrenched in JavaFX, I see no advantage in trying to fight it.
However, I agree that we should clearly define what left and right
means in the context of RTL layouts, which is a bit different from the
usual dictionary definition of left and right.


On Tue, Oct 14, 2025 at 7:08?PM Andy Goryachev
 wrote:
>
> I would rather clarify the incorrect labels in the existing components.  We obviously cannot change setLeft() - perhaps we should add explanation to the corresponding javadoc explaining RTL behavior.  I would like to avoid making the same mistake going forward.
>
> -andy

From kcr at openjdk.org  Tue Oct 14 19:33:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Oct 2025 19:33:20 GMT
Subject: RFR: 8089514: [TableView, TreeView, ListView,
 TreeTableView] Clicking outside of the edited cell, node,
 or entry should commit the value
In-Reply-To: 
References: 
Message-ID: 

On Mon, 13 Oct 2025 12:19:52 GMT, Marius Hanl  wrote:

> This is an initial poc for the long standing issue of allowing to commit a cell value when the focus is lost or the editing index (cell) changed. This also contains [JDK-8089311](https://bugs.openjdk.org/browse/JDK-8089311) (for better understanding the usecase with `TextFiield` cells, but we may split this later on).
> 
> API
> -
> - Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the focus is lost or the editing index changed. The default behavior is cancelling the edit, but developers can now override the behavior and allow a `commitEdit` instead
> - There are multiple 'events' that can lead to a editing change. Every change will now call `stopEdit`.
> It is therefore the responsibility of the developer to decide, when it makes sense to actually commit the value instead of cancelling it. This decision was made as the behavior is manipulating the editing index, but you as a developer can as well. We do not really know what intention led to e.g. a change of the editing index.
> - Every `MOUSE_PRESSED` shifts the focus to the cell container, which is undesired in case of editing the cell. So this event is now consumed.
> - All `TextField` cells now commit their value (instead of cancel) on focus loss
> - `TextField` Escape handling was badly implemented (it was never really called, as the cell container handled Escape before)
> 
> Considerations
> -
> - I tried to make the API minimal, and without breaking changes (other than the `TextField` cells committing their values, but we may split this up)
> - The Cell Container focus behavior is, well, weird right now. That is why consuming the event is needed to better support this PR. One thing we may can consider is using the `focusWithin` property instead for all 4 Cell Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` event. If we decide so, this is needs to be done before merging this PR.
> - Clicking the `ScrollBar` now commits/cancels the edit. I checked other applications and this is very common. But something I need to note here. This probably can be fixed in the same way mentioned above (`focusWithin`)
> - It might be hard for a developer to exactly know the cause why `stopEdit` is called. This does not seem like a problem, as e.g. for a `TextField`, you normally register listeners for e.g. pressing the Escape key on it, so you keep full control.
> 
> Another Approach
> -
> - Another Approach I tested could be to request the focus to a cell when clicked/edited, to ensure that the focus listener i...

I think this needs more discussion before it is ready for formal review. Perhaps it should be moved to Draft until the discussion converges on an approach?

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

PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-3403306288

From kcr at openjdk.org  Tue Oct 14 19:42:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Oct 2025 19:42:24 GMT
Subject: [jfx25u] Integrated: 8369140: GHA: Update macOS / x64 build to use
 macos-15-intel runner
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Oct 2025 00:21:15 GMT, Kevin Rushforth  wrote:

> Clean backport of GHA fix to jfx25u.

This pull request has now been integrated.

Changeset: 05d3a219
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx25u/commit/05d3a21999f3577445eedde8c09b05d63f55ecd4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8369140: GHA: Update macOS / x64 build to use macos-15-intel runner

Reviewed-by: jvos
Backport-of: e8820e2482bbc00765975854e738fdc214a46ea4

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

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

From jhendrikx at openjdk.org  Wed Oct 15 03:46:13 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 15 Oct 2025 03:46:13 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
Message-ID: 

This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.

Justification for this change is to allow an `ObservableList` to be bulk modified in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting not in two listener callbacks in between which the size of the list can be observed to change.

The other alternative is to call `set` individually for each item, which results in many change notifications.

With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.

(*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

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

Commit messages:
 - Implement setAll with range for ObservableList

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

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

From nlisker at gmail.com  Wed Oct 15 07:35:33 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 15 Oct 2025 10:35:33 +0300
Subject: Building openjfx
In-Reply-To: <862c9832-c921-401c-b387-e138bd8fb92b@oracle.com>
References: <17f37f37-6e98-4261-88d8-d2f91c92e607@nwra.com>
 <862c9832-c921-401c-b387-e138bd8fb92b@oracle.com>
Message-ID: 

>
> Ah yes, you are running into one of the charming issues with using
> gradle: namely, gradle is slow in supporting the latest JDKs.


The newer gradle versions support the new Java versions rather quickly.
Gradle supported JDK 25 already a couple of days later and Java 23 even
before its release.

The easiest way is to use JDK 24.x (e.g., 24.0.2) to both run gradle and
> build JavaFX. This is what we do.


 The right way to do it is to use the Gradle toolchain support to define a
Java version to build with, which has been available since Gradle 6-7. Then
the Gradle Java version and the JavaFX Java version are decoupled.

I understand that it's not worth doing any work on the Gradle files since
they are planned to be replaced with the JDK's build system.

On Tue, Oct 14, 2025 at 7:31?PM Kevin Rushforth 
wrote:

> Ah yes, you are running into one of the charming issues with using
> gradle: namely, gradle is slow in supporting the latest JDKs.
>
> The easiest way is to use JDK 24.x (e.g., 24.0.2) to both run gradle and
> build JavaFX. This is what we do.
>
> If you need to use JDK 25 to build, you will need two JDKs: one to run
> gradle (JDK 24 or earlier) and another to use for building. Point
> JAVA_HOME to the JDK used to launch gradle and put it in your PATH.
> Point JDK_HOME to the JDK 25 that you will use to build JavaFX.
>
> -- Kevin
>
>
>
> On 10/13/2025 5:22 PM, Orion Poplawski wrote:
> > So I'm stepping back to simply try building openjfx with gradlew but I
> > get:
> >
> > $ sh gradlew --info build
> > Initialized native services in: /home/orion/.gradle/native
> > Initialized jansi services in: /home/orion/.gradle/native
> > The client will now receive all logging from the daemon (pid: 253483).
> > The daemon log file:
> > /home/orion/.gradle/daemon/8.14.2/daemon-253483.out.log
> > Starting 2nd build in daemon [uptime: 2 mins 22.763 secs, performance:
> > 97%, GC rate: 0.00/s, heap usage: 2% of 512 MiB, non-heap usage: 9% of
> > 384 MiB]
> > Using 6 worker leases.
> > Now considering [/home/orion/openjfx-25/jfx25u-25-29] as hierarchies
> > to watch
> > Now considering [/home/orion/openjfx-25/jfx25u-25-29/buildSrc,
> > /home/orion/openjfx-25/jfx25u-25-29] as hierarchies to watch
> > Watching the file system is configured to be enabled if available
> > File system watching is active
> > Starting Build
> > Caching disabled for Groovy DSL script compilation (settings) because:
> >   Build cache is disabled
> >   Not worth caching.
> > Compiling settings file
> > '/home/orion/openjfx-25/jfx25u-25-29/settings.gradle' using
> > BuildScriptTransformer.
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > BUG! exception in phase 'semantic analysis' in source unit
> > '_BuildScript_' Unsupported class file major version 69
> > > Unsupported class file major version 69
> >
> > * Try:
> > > Run with --stacktrace option to get the stack trace.
> > > Run with --debug option to get more log output.
> > > Run with --scan to get full insights.
> > > Get more help at https://help.gradle.org.
> >
> > BUILD FAILED in 466ms
> >
> > $ java --version
> > openjdk 25 2025-09-16
> > OpenJDK Runtime Environment (Red_Hat-25.0.0.0.36-1) (build 25+36)
> > OpenJDK 64-Bit Server VM (Red_Hat-25.0.0.0.36-1) (build 25+36, mixed
> > mode, sharing)
> >
> > What am I doing wrong?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nlisker at openjdk.org  Wed Oct 15 09:09:19 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 15 Oct 2025 09:09:19 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 03:40:24 GMT, John Hendrikx  wrote:

> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

How about doing this through the SubList view? JavaFX's implementation already has a `SubObservableList` inner class that propagates changes on it to the list's listeners:

		ObservableList list = FXCollections.observableArrayList();
		list.addAll(0, 1, 2, 3, 4, 5, 6);
		list.addListener((ListChangeListener) c -> System.out.println(c));
		List subList = list.subList(2, 4);
		System.out.println(list);
		System.out.println(subList);
		subList.clear(); // equivalent to list.remove(2, 4);

prints

[0, 1, 2, 3, 4, 5, 6]
[2, 3]
{ [2, 3] removed at 2 }


 The issue is that it's a `List` and not an `ObservableList`, so it doesn't have JavaFX's additional bulk operation methods. However, "just" having `ObservableList#subList` return an `ObservableList` will allow to make all range operations easily:

		ObservableList list = FXCollections.observableArrayList();
		list.addAll(0, 1, 2, 3, 4, 5, 6);
		list.addListener((ListChangeListener) c -> System.out.println(c));
		ObservableList subList = list.subList(2, 4); // suggestion
		subList.setAll(7, 8);

I think that this would be more flexible/composable and result in a smaller API surface (current bulk methods would also be made redundant technically).

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3405348899

From mstrauss at openjdk.org  Wed Oct 15 12:04:34 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 15 Oct 2025 12:04:34 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 09:05:54 GMT, Nir Lisker  wrote:

> The issue is that it's a `List` and not an `ObservableList`, so it doesn't have JavaFX's additional bulk operation methods. However, "just" having `ObservableList#subList` return an `ObservableList` will allow to make all range operations easily:

This change would be neither source compatible nor binary compatible, so this probably rules it out.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3406058160

From mstrauss at openjdk.org  Wed Oct 15 12:13:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 15 Oct 2025 12:13:54 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
Message-ID: 

On Wed, 15 Oct 2025 03:40:24 GMT, John Hendrikx  wrote:

> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

modules/javafx.base/src/main/java/javafx/collections/ObservableList.java line 92:

> 90:      *
> 91:      * @param index the start index at which to replace elements, must be in
> 92:      *              {@code 0 .. size() - col.size()}

This seems to be an unnecessary limitation. It means that as a result of this operation, ~~the list can only be shorter, but not longer~~ the size of the list must stay the same. The `setAll(int, int, Collection)` overload doesn't have this limitation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2432315088

From jhendrikx at openjdk.org  Wed Oct 15 12:31:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 15 Oct 2025 12:31:06 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
Message-ID: <_lt9Zvb_iZeuNZYBy98TDY3MCl0cREz6jdbYmVspPr4=.068ae444-d04e-441c-8baf-418c6ebea158@github.com>

On Wed, 15 Oct 2025 03:40:24 GMT, John Hendrikx  wrote:

> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

> How about doing this through the SubList view? JavaFX's implementation already has a `SubObservableList` inner class that propagates changes on it to the list's listeners:
> 
> I think that this would be more flexible/composable and result in a smaller API surface (current bulk methods would also be made redundant technically).

This is the first thing I tried, but we can't change the return type of `ObservableList#subList`.  So you'd be forced to do a cast to get access to the `setAll` method which is `ObservableList` specific.  Aside from that, I don't know what would happen if `SubObservableList` becomes a full `ObservableList` (with listeners, etc) as it currently definitely does not take such use into account (it basically is only using a standard `List` as its input).  For sure that would require many tests, and I'm not looking forward to ensure that listening on some random sublist will behave properly in cases where the main list was modified (but did not include the sublist range), or when it did include only **part** of the sublist range (would need to transform the `Change` provided I think), etc...

I thought about just not allowing listeners on these sublists, but the required cast still is super annoying.

So, since `ObservableList` has already decided to extend the `List` interface with additional methods (`setAll`, `remove(int, int)`) I think doing it in the proposed way is much simpler and in line with what is already there.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3406160998

From jhendrikx at openjdk.org  Wed Oct 15 12:41:17 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 15 Oct 2025 12:41:17 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 12:08:36 GMT, Michael Strau?  wrote:

>> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> modules/javafx.base/src/main/java/javafx/collections/ObservableList.java line 92:
> 
>> 90:      *
>> 91:      * @param index the start index at which to replace elements, must be in
>> 92:      *              {@code 0 .. size() - col.size()}
> 
> This seems to be an unnecessary limitation. It means that as a result of this operation, ~~the list can only be shorter, but not longer~~ the size of the list must stay the same. The `setAll(int, int, Collection)` overload doesn't have this limitation.

Initially, I only wanted to support a "pure" `set` function (to avoid a `set(int)` loop + notifications), where you can have a range of elements replaced by another range of the exact same size (so an `int` and `Collection` is enough to define this).  However, there was an open ticket to have a variant `(from, to, Collection)` which is more powerful, but is not truly a "set" function anymore IMHO.

I figured I could implement both, but I think having only `set(int, Collection)` would be sufficient for most use cases.

I suppose it is possible to relax this, but it would have a bit of weird usage I think:

     List.of(A, B, C, D).setAll(1, List.of(E, F, G))  -> A, E, F, G
     List.of(A, B, C, D).setAll(2, List.of(E, F, G))  -> A, B, E, F, G
     List.of(A, B, C, D).setAll(3, List.of(E, F, G))  -> A, B, C, E, F, G
     
Now it can also extend the collection, which looks weird.  The other `setAll(from, to, col)` does indeed allow this, but perhaps it shouldn't be called `setAll` as it is not strictly doing what a loop of `set` calls normally could be doing...

Perhaps I shouldn't have attempted to reuse an old ticket, and just keep it simple with only a `setAll(int, Collection)`...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2432401418

From mstrauss at openjdk.org  Wed Oct 15 13:03:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 15 Oct 2025 13:03:40 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 15 Oct 2025 12:38:08 GMT, John Hendrikx  wrote:

>> modules/javafx.base/src/main/java/javafx/collections/ObservableList.java line 92:
>> 
>>> 90:      *
>>> 91:      * @param index the start index at which to replace elements, must be in
>>> 92:      *              {@code 0 .. size() - col.size()}
>> 
>> This seems to be an unnecessary limitation. It means that as a result of this operation, ~~the list can only be shorter, but not longer~~ the size of the list must stay the same. The `setAll(int, int, Collection)` overload doesn't have this limitation.
>
> Initially, I only wanted to support a "pure" `set` function (to avoid a `set(int)` loop + notifications), where you can have a range of elements replaced by another range of the exact same size (so an `int` and `Collection` is enough to define this).  However, there was an open ticket to have a variant `(from, to, Collection)` which is more powerful, but is not truly a "set" function anymore IMHO.
> 
> I figured I could implement both, but I think having only `set(int, Collection)` would be sufficient for most use cases.
> 
> I suppose it is possible to relax this, but it would have a bit of weird usage I think:
> 
>      List.of(A, B, C, D).setAll(1, List.of(E, F, G))  -> A, E, F, G
>      List.of(A, B, C, D).setAll(2, List.of(E, F, G))  -> A, B, E, F, G
>      List.of(A, B, C, D).setAll(3, List.of(E, F, G))  -> A, B, C, E, F, G
>      
> Now it can also extend the collection, which looks weird.  The other `setAll(from, to, col)` does indeed allow this, but perhaps it shouldn't be called `setAll` as it is not strictly doing what a loop of `set` calls normally could be doing...
> 
> Perhaps I shouldn't have attempted to reuse an old ticket, and just keep it simple with only a `setAll(int, Collection)`...

You're restricting functionality because you perceive the usage to be weird. No other bulk operation does this without technical necessity. Now, to me it doesn't look weird, but that's besides the point. I don't think a general-purpose API should police subjective weirdness.

As far as naming is concerned, the `setAll(int, int, Collection)` overload might also be called `replace` or `replaceRange`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2432473831

From mhanl at openjdk.org  Wed Oct 15 13:58:58 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 15 Oct 2025 13:58:58 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
Message-ID: 

On Mon, 13 Oct 2025 16:30:14 GMT, Kevin Rushforth  wrote:

>> I would rather explain it at the top level, since it is the class the app devs use, instead of referring to some part of the skin in another package.
>> 
>> And what if the control uses a custom skin that is not based on the `VirtualFlow`?
>> 
>> In fact, the public method in this Control is the normative one, so it must define the expected behavior for all the implementors to follow.
>
>> In fact, the public method in this Control is the normative one, so it must define the expected behavior for all the implementors to follow.
> 
> You're absolutely right.

> And what if the control uses a custom skin that is not based on the `VirtualFlow`?

But that can also be used against using the description from `VirtualFlow`. Right now, I would insist to not add any more details, as the rebuild implementation may change later on. 

Right now, we remove and add them to the viewport, but this is not really needed. What we want to achieve is that `updateItem` is called, and this way ensures that. But there are other, better and faster ways to do so. Something I might revisit at one point in the future.

And since the `In other words` explains why this useful, I think we are good here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2432669082

From zjx001202 at gmail.com  Wed Oct 15 14:21:01 2025
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 15 Oct 2025 22:21:01 +0800
Subject: StageStyle.EXTENDED with transparent background
Message-ID: 

Hi,

Our application has traditionally used StageStyle.TRANSPARENT to enable a
fully customizable stage.
This allows users to set custom backgrounds and adjust the window's opacity
freely, leveraging our powerful personalization features.

After the release of JavaFX 25, we want to migrate to StageStyle.EXTENDED
so that
we can use native window decorations and no longer need to draw window
shadows ourselves.
But using StageStyle.EXTENDED creates a stage with a white background,
which prevents us
from setting the window's opacity.
So is there any way we can make the stage background transparent while
using StageStyle.EXTENDED?

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mariushanl at web.de  Wed Oct 15 14:39:26 2025
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 15 Oct 2025 14:39:26 +0000
Subject: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From jhendrikx at openjdk.org  Wed Oct 15 14:41:18 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 15 Oct 2025 14:41:18 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 13:00:14 GMT, Michael Strau?  wrote:

>> Initially, I only wanted to support a "pure" `set` function (to avoid a `set(int)` loop + notifications), where you can have a range of elements replaced by another range of the exact same size (so an `int` and `Collection` is enough to define this).  However, there was an open ticket to have a variant `(from, to, Collection)` which is more powerful, but is not truly a "set" function anymore IMHO.
>> 
>> I figured I could implement both, but I think having only `set(int, Collection)` would be sufficient for most use cases.
>> 
>> I suppose it is possible to relax this, but it would have a bit of weird usage I think:
>> 
>>      List.of(A, B, C, D).setAll(1, List.of(E, F, G))  -> A, E, F, G
>>      List.of(A, B, C, D).setAll(2, List.of(E, F, G))  -> A, B, E, F, G
>>      List.of(A, B, C, D).setAll(3, List.of(E, F, G))  -> A, B, C, E, F, G
>>      
>> Now it can also extend the collection, which looks weird.  The other `setAll(from, to, col)` does indeed allow this, but perhaps it shouldn't be called `setAll` as it is not strictly doing what a loop of `set` calls normally could be doing...
>> 
>> Perhaps I shouldn't have attempted to reuse an old ticket, and just keep it simple with only a `setAll(int, Collection)`...
>
> You're restricting functionality because you perceive the usage to be weird. No other bulk operation does this without technical necessity. Now, to me it doesn't look weird, but that's besides the point. I don't think a general-purpose API should police subjective weirdness.
> 
> As far as naming is concerned, the `setAll(int, int, Collection)` overload might also be called `replace` or `replaceRange`.

I was restricting it because "set" does not allow you to add an element either when giving `size()` as the index.  I only belatedly realized that `setAll(int, int, Collection)` is violating this, and allows to add elements and so changes the list size.

Naming is really important, so calling the range method `setAll` then is I think a poor choice.  So the possible methods we could introduce are:

- `setAll(int, Collection)` and disallow it to change size; this method is a combination of `setAll(Collection)` and `set(int, T)` similar to how `addAll(int, Collection)` is a combination of `add(int, T)` and `addAll(Collection)`. 
- `replaceAll(int, Collection)` similar to the above, but allows adding of elements if it runs out of elements to update
- `replaceAll(int, int, Collection)` a proper name for `setAll(int, int, Collection)` (`splice` was also suggested in the ticket).

For me I'd either go with:
- Have `setAll(int, Collection)`
- Have both `setAll(int, Collection)` and `replaceAll(int, int, Collection)`

The `replaceAll(int, Collection)` I think does not carry its weight, and would just be confusing given that there would be a much more clear variant `replaceAll(int, int, Collection)`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2432834214

From john.hendrikx at gmail.com  Wed Oct 15 15:04:59 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 15 Oct 2025 17:04:59 +0200
Subject: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
 
Message-ID: <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>

Hi Marius,

Focus lost is currently sort of a proxy of starting an interaction with
a new control, but not all controls gain focus when interacted with.?
Buttons are one of those (either with mouse press or keyboard short
cut), but there is I think also the scroll wheel that can interact with
a control without focusing it (and perhaps even popup menu's).

I can only think of one half-baked solution to this:

- Have a new Event type that is always targetted at the current focus
owner ("InterestLostEvent" ? :))
- This event is automatically fired by Scene just before an event is
fired that is?not targetted at the current focus owner, AND the last
event fired did have the focus owner as target

What would happen in practice then would be something like:

- User edits field, keypress events go to current focus owner
- User does something else (moves mouse, scrolls, presses a hotkey, or
presses a button):
??? - An InterestLostEvent is fired at the current focus owner BEFORE
the new event is fired
??? - The delayed new event is now fired
??? - No further InterestLostEvents are fired until the focus owner has
received a normal event again
- User goes back to editing after playing with the mouse; events
targetted at the focus owner renew the interest in that control, and so
next time an InterestLostEvent is fired again when needed

It feels a bit awkward, especially because simple things like mouse
moves may trigger it already (but a mouse move may trigger something
that requires the model to be up to date...); perhaps it would need to
be selective in some way so one can choose to only be interested in the
InterestLostEvent on focus loss and mouse clicks.

I can immediately see some problems as well.? Some controls I think
allow editing without focus gain/loss at all (I think some controls can
be edited by just scrolling the mouse wheel over them).? When should
those controls "commit" their values...?

--John


On 15/10/2025 16:39, Marius Hanl wrote:
> Hi John,
> ?
> you are right that there might be corner cases.?I hope that we?could,
> what Andy suggests, find all cases and have a deeper look at them.
> We can also check whether the focus delegation API from Michael is
> something that could help us here (but might be completely unrelated).
> ?
> The other options as you also mentioned,?also have their problems.
> Even debouncing a commit on every keystroke can be unreliable if the
> user is too fast.
> I really hope we can make the focus loss reliable, as we then do not
> need much of an API changes inside the Cell Framework.
> ?
> -- Marius
> *Gesendet: *Montag, 13. Oktober 2025 um 19:32
> *Von: *"Andy Goryachev" 
> *An: *"John Hendrikx" ,
> "openjfx-dev at openjdk.org" 
> *Betreff: *Re: Allowing a cell to commit the value on focus loss
> I wonder if we should find out exactly why onFocusLost does not work
> in these cases, as expected. ?Then, if I understand the proposal
> correctly, we won't need any API changes.
> ?
> -andy
> ?
> ?
> ?
> *From: *openjfx-dev  on behalf of John
> Hendrikx 
> *Date: *Monday, October 13, 2025 at 07:17
> *To: *openjfx-dev at openjdk.org 
> *Subject: *Re: Allowing a cell to commit the value on focus loss
>
> Hi Marius,
>
> This may be unrelated, but it may be problematic to rely on committing
> values using focus lost:
>
> I've built a lot of code that relies on focus lost to "commit" values
> to some underlying model.? However, I noticed that a focus lost
> handler for committing values is insufficient when an action is
> triggered that doesn't trigger a loss of focus.?? For example, if I
> have a field "email address" and a Button "Send Email", and I have a
> focus lost handler to commit the email address textfield to an
> underlying model, then pressing the Button will not trigger that
> handler and the underlying model may not have been updated with the
> latest edits.
>
> Solutions to trigger the correct action are all a bit tricky or annoying:
>
> - Query all fields for their current contents as focus lost is not
> entirely reliable for this purpose
> - Have fields update models immediately (which would be on every key
> press...) -- this is not very efficient, and can get in the way of
> validation / model restrictions
> - Have controls listen to a "COMMIT" event (this is fired at the
> current focus owner by the Button).? This event may be veto'd if
> committing the value resulted in a validation error, in which case the
> button press is cancelled
>
> I don't like any of these, but using the last option at the moment
> because I like constant updates and having to requery UI components
> even less...
>
> --John
>
>
> I noticed however that if you edit some field (it doesn't have to be
> in a table view, just a regular field), and have a focus lost handler
> that commits the value, that this focus lost handler is insufficient...
>
> On 13/10/2025 14:53, mariushanl at web.de?wrote:
>
>     All,
>     ?
>     I created an initial poc 1* to support developers to commit the
>     cell value when the focus is lost 2* (including 3*).
>     More specifically, this gives the maximum flexibility to choose
>     what should happen when the focus is lost or the editing index
>     changed (which may happen when clicking into another cell while
>     editing).
>     All information mentioned here are also in the description of the PR.
>     ?
>     *API*
>     *?*
>     - Instead of calling `/cancelEdit/`, every cell now calls
>     `/stopEdit/` when the focus is lost or the editing index changed.
>     The default behavior is cancelling the edit, but developers can
>     now override the behavior and allow a `/commitEdit/` instead
>     - There are multiple 'events' that can lead to a editing change.
>     Every change will now call `/stopEdit/`.
>     It is therefore the responsibility of the developer to decide,
>     when it makes sense to actually commit the value instead of
>     cancelling it. This decision was made as the behavior is
>     manipulating the editing index, but you as a developer can as
>     well. We do not really know what intention led to e.g. a change of
>     the editing index.
>     - Every `/MOUSE_PRESSED/` shifts the focus to the cell container,
>     which is undesired in case of editing the cell. So this event is
>     now consumed.
>     - All `/TextField/` cells now commit their value (instead of
>     cancel) on focus loss
>     - `/TextField/` Escape handling was badly implemented (it was
>     never really called, as the cell container handled Escape before)
>     ?
>     *Considerations*
>
>     - I tried to make the API minimal, and without breaking changes
>     (other than the `/TextField/` cells committing their values, but
>     we may split this up)
>     - The Cell Container focus behavior is, well, weird right now.
>     That is why consuming the event is needed to better support this
>     PR. One thing we may can consider is using the `/focusWithin/`
>     property instead for all 4 Cell Containers and not calling
>     `/requestFocus/` for nearly every `/MOUSE_PRESSED/` event. If we
>     decide so, this is needs to be done before merging this PR.
>     - Clicking the `/ScrollBar/` now commits/cancels the edit. I
>     checked other applications and this is very common. But something
>     I need to note here. This probably can be fixed in the same way
>     mentioned above (`/focusWithin/`)
>     - It might be hard for a developer to exactly know the cause why
>     `/stopEdit/` is called. This does not seem like a problem, as e.g.
>     for a `/TextField/`, you normally register listeners for e.g.
>     pressing the Escape key on it, so you keep full control.
>     ?
>     *Another Approach*
>
>     - Another Approach I tested could be to request the focus to a
>     cell when clicked/edited, to ensure that the focus listener is
>     ALWAYS called before another cell will reach the editing state.
>     Again, we probably need to change the focus handling to e.g. use
>     the `/focusWithin/` property. With this approach, we can only call
>     `/stopEdit` /when the focus changed (since it is now called
>     always), but not when the editing index changed.
>     ?
>     1* - https://github.com/openjdk/jfx/pull/1935
>     2* - https://bugs.openjdk.org/browse/JDK-8089514
>     3* - https://bugs.openjdk.org/browse/JDK-8089311
>     ?
>     -- Marius
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Wed Oct 15 15:12:14 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 15 Oct 2025 15:12:14 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 14:38:54 GMT, John Hendrikx  wrote:

>> You're restricting functionality because you perceive the usage to be weird. No other bulk operation does this without technical necessity. Now, to me it doesn't look weird, but that's besides the point. I don't think a general-purpose API should police subjective weirdness.
>> 
>> As far as naming is concerned, the `setAll(int, int, Collection)` overload might also be called `replace` or `replaceRange`.
>
> I was restricting it because "set" does not allow you to add an element either when giving `size()` as the index.  I only belatedly realized that `setAll(int, int, Collection)` is violating this, and allows to add elements and so changes the list size.
> 
> Naming is really important, so calling the range method `setAll` then is I think a poor choice.  So the possible methods we could introduce are:
> 
> - `setAll(int, Collection)` and disallow it to change size; this method is a combination of `setAll(Collection)` and `set(int, T)` similar to how `addAll(int, Collection)` is a combination of `add(int, T)` and `addAll(Collection)`. 
> - `replaceAll(int, Collection)` similar to the above, but allows adding of elements if it runs out of elements to update
> - `replaceAll(int, int, Collection)` a proper name for `setAll(int, int, Collection)` (`splice` was also suggested in the ticket).
> 
> For me I'd either go with:
> - Have `setAll(int, Collection)`
> - Have both `setAll(int, Collection)` and `replaceAll(int, int, Collection)`
> 
> The `replaceAll(int, Collection)` I think does not carry its weight, and would just be confusing given that there would be a much more clear variant `replaceAll(int, int, Collection)`.

* `setAll(int, Collection)` and disallow it to change size
I think this doesn't carry its weight. It's just an explicit name for a narrow special case of a more general operation. However, if we're going to have a method with this signature, I suggest to not go for the narrow special case, but instead at least allow me to overlap the new list across the end of the existing list.

* `replaceAll(int, int, Collection)`
We already have `List.replaceAll(UnaryOperator)`, which does something quite different (namely, replacing all elements with different elements). I think your proposed operation really is more like a `replaceRange`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2432953994

From andy.goryachev at oracle.com  Wed Oct 15 15:20:26 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 15 Oct 2025 15:20:26 +0000
Subject: [External] : Re: Allowing a cell to commit the value on focus loss
In-Reply-To: <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
 
 <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>
Message-ID: 

  *
Buttons are one of those (either with mouse press or keyboard short cut)

This looks like a bug to me, really.  What is the main purpose of the focus subsystem?
I know we like to reinvent the wheel, but focus in Swing works as expected, and one does get focus lost event on mouse press, and the target button gets the focus.  Why should FX be different?

-andy


From: John Hendrikx 
Date: Wednesday, October 15, 2025 at 08:05
To: Marius Hanl , Andy Goryachev , openjfx-dev at openjdk.org 
Subject: [External] : Re: Allowing a cell to commit the value on focus loss


Hi Marius,

Focus lost is currently sort of a proxy of starting an interaction with a new control, but not all controls gain focus when interacted with.  Buttons are one of those (either with mouse press or keyboard short cut), but there is I think also the scroll wheel that can interact with a control without focusing it (and perhaps even popup menu's).

I can only think of one half-baked solution to this:

- Have a new Event type that is always targetted at the current focus owner ("InterestLostEvent" ? :))
- This event is automatically fired by Scene just before an event is fired that is not targetted at the current focus owner, AND the last event fired did have the focus owner as target

What would happen in practice then would be something like:

- User edits field, keypress events go to current focus owner
- User does something else (moves mouse, scrolls, presses a hotkey, or presses a button):
    - An InterestLostEvent is fired at the current focus owner BEFORE the new event is fired
    - The delayed new event is now fired
    - No further InterestLostEvents are fired until the focus owner has received a normal event again
- User goes back to editing after playing with the mouse; events targetted at the focus owner renew the interest in that control, and so next time an InterestLostEvent is fired again when needed

It feels a bit awkward, especially because simple things like mouse moves may trigger it already (but a mouse move may trigger something that requires the model to be up to date...); perhaps it would need to be selective in some way so one can choose to only be interested in the InterestLostEvent on focus loss and mouse clicks.

I can immediately see some problems as well.  Some controls I think allow editing without focus gain/loss at all (I think some controls can be edited by just scrolling the mouse wheel over them).  When should those controls "commit" their values...?

--John


On 15/10/2025 16:39, Marius Hanl wrote:
Hi John,

you are right that there might be corner cases. I hope that we could, what Andy suggests, find all cases and have a deeper look at them.
We can also check whether the focus delegation API from Michael is something that could help us here (but might be completely unrelated).

The other options as you also mentioned, also have their problems. Even debouncing a commit on every keystroke can be unreliable if the user is too fast.
I really hope we can make the focus loss reliable, as we then do not need much of an API changes inside the Cell Framework.

-- Marius
Gesendet: Montag, 13. Oktober 2025 um 19:32
Von: "Andy Goryachev" 
An: "John Hendrikx" , "openjfx-dev at openjdk.org" 
Betreff: Re: Allowing a cell to commit the value on focus loss
I wonder if we should find out exactly why onFocusLost does not work in these cases, as expected.  Then, if I understand the proposal correctly, we won't need any API changes.

-andy



From: openjfx-dev  on behalf of John Hendrikx 
Date: Monday, October 13, 2025 at 07:17
To: openjfx-dev at openjdk.org 
Subject: Re: Allowing a cell to commit the value on focus loss


Hi Marius,

This may be unrelated, but it may be problematic to rely on committing values using focus lost:

I've built a lot of code that relies on focus lost to "commit" values to some underlying model.  However, I noticed that a focus lost handler for committing values is insufficient when an action is triggered that doesn't trigger a loss of focus.   For example, if I have a field "email address" and a Button "Send Email", and I have a focus lost handler to commit the email address textfield to an underlying model, then pressing the Button will not trigger that handler and the underlying model may not have been updated with the latest edits.

Solutions to trigger the correct action are all a bit tricky or annoying:

- Query all fields for their current contents as focus lost is not entirely reliable for this purpose
- Have fields update models immediately (which would be on every key press...) -- this is not very efficient, and can get in the way of validation / model restrictions
- Have controls listen to a "COMMIT" event (this is fired at the current focus owner by the Button).  This event may be veto'd if committing the value resulted in a validation error, in which case the button press is cancelled

I don't like any of these, but using the last option at the moment because I like constant updates and having to requery UI components even less...

--John

I noticed however that if you edit some field (it doesn't have to be in a table view, just a regular field), and have a focus lost handler that commits the value, that this focus lost handler is insufficient...

On 13/10/2025 14:53, mariushanl at web.de wrote:
All,

I created an initial poc 1* to support developers to commit the cell value when the focus is lost 2* (including 3*).
More specifically, this gives the maximum flexibility to choose what should happen when the focus is lost or the editing index changed (which may happen when clicking into another cell while editing).
All information mentioned here are also in the description of the PR.

API

- Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the focus is lost or the editing index changed. The default behavior is cancelling the edit, but developers can now override the behavior and allow a `commitEdit` instead
- There are multiple 'events' that can lead to a editing change. Every change will now call `stopEdit`.
It is therefore the responsibility of the developer to decide, when it makes sense to actually commit the value instead of cancelling it. This decision was made as the behavior is manipulating the editing index, but you as a developer can as well. We do not really know what intention led to e.g. a change of the editing index.
- Every `MOUSE_PRESSED` shifts the focus to the cell container, which is undesired in case of editing the cell. So this event is now consumed.
- All `TextField` cells now commit their value (instead of cancel) on focus loss
- `TextField` Escape handling was badly implemented (it was never really called, as the cell container handled Escape before)

Considerations

- I tried to make the API minimal, and without breaking changes (other than the `TextField` cells committing their values, but we may split this up)
- The Cell Container focus behavior is, well, weird right now. That is why consuming the event is needed to better support this PR. One thing we may can consider is using the `focusWithin` property instead for all 4 Cell Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` event. If we decide so, this is needs to be done before merging this PR.
- Clicking the `ScrollBar` now commits/cancels the edit. I checked other applications and this is very common. But something I need to note here. This probably can be fixed in the same way mentioned above (`focusWithin`)
- It might be hard for a developer to exactly know the cause why `stopEdit` is called. This does not seem like a problem, as e.g. for a `TextField`, you normally register listeners for e.g. pressing the Escape key on it, so you keep full control.

Another Approach

- Another Approach I tested could be to request the focus to a cell when clicked/edited, to ensure that the focus listener is ALWAYS called before another cell will reach the editing state. Again, we probably need to change the focus handling to e.g. use the `focusWithin` property. With this approach, we can only call `stopEdit` when the focus changed (since it is now called always), but not when the editing index changed.

1* - https://github.com/openjdk/jfx/pull/1935
2* - https://bugs.openjdk.org/browse/JDK-8089514
3* - https://bugs.openjdk.org/browse/JDK-8089311

-- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Wed Oct 15 15:25:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Oct 2025 15:25:13 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
Message-ID: 

On Wed, 15 Oct 2025 13:55:41 GMT, Marius Hanl  wrote:

>>> In fact, the public method in this Control is the normative one, so it must define the expected behavior for all the implementors to follow.
>> 
>> You're absolutely right.
>
>> And what if the control uses a custom skin that is not based on the `VirtualFlow`?
> 
> But that can also be used against using the description from `VirtualFlow`. Right now, I would insist to not add any more details, as the rebuild implementation may change later on. 
> 
> Right now, we remove and add them to the viewport, but this is not really needed. What we want to achieve is that `updateItem` is called, and this way ensures that. But there are other, better and faster ways to do so. Something I might revisit at one point in the future.
> 
> And since the `In other words` explains why this useful, I think we are good here.

I still don't know what "rebuild" means in this context.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2433003265

From andy.goryachev at oracle.com  Wed Oct 15 16:20:21 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 15 Oct 2025 16:20:21 +0000
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
 <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>
 <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>
Message-ID: 

Another consideration is backporting.  So, despite my earlier support for markdown comments, I reverse my position and say that we should avoid it for the time being.

-andy

From: openjfx-dev  on behalf of Kevin Rushforth 
Date: Friday, October 10, 2025 at 12:26
To: openjfx-dev at openjdk.org 
Subject: Re: Using markdown-style javadoc comments (JEP 467)

I informally polled a few folks in the core libs group. They haven't
started using it in the JDK yet, but would consider it primarily for new
classes; some felt as Michael did that mixing styles in the same class
would be annoying.

I can see the argument for consistency, especially in a file like Node
or Control, where we have many existing properties and other methods.
For additions of a new property or method in such a file, consistency
seems more important than being able to use markdown.

In cases where there aren't so many methods, or where you are already
modifying many of them, it might be reasonable to use markdown for new
or modified methods.

Perhaps as a compromise, we could consider allowing for new classes and
classes where you are modifying a large percentage of the existing docs
anyway, but in general, avoid using markdown in existing classes.

Concretely, that would mean asking Nir to update PR 1873 [1] to not use
markdown-style doc comments (it seems gratuitous there anyway, since it
isn't using any markdown syntax), but allow the use of markdown in PR
1880 [2].

Thoughts?

-- Kevin

[1] https://github.com/openjdk/jfx/pull/1873
[2] https://github.com/openjdk/jfx/pull/1880


On 10/7/2025 6:33 AM, John Hendrikx wrote:
> I'm of the same mind.  I don't see a use case for markdown comments at
> all in a
> project as mature as JavaFX, and I'm unlikely to use them, even for new
> files simply to be
> more consistent with other existing files (and I may copy/paste docs
> sometimes as well).
>
> There are barely any code conventions in FX as it is (indent is 4
> spaces, and general Java naming
> conventions are the only ones that I think of that are consistent
> through-out the project), but
> a consistent Javadoc style can also be considered one currently... still.
>
> --John
>
> On 07/10/2025 10:47, Michael Strau? wrote:
>> Markdown comments are not _better_ than HTML comments, they are just
>> different. In particular, I question the unsubstantiated claim that
>> markdown comments are more readable; I've never once struggled with
>> reading HTML comments, especially if you use the recent additions like
>> {@snippet}.
>>
>> I might use markdown comments myself if I were to start a greenfield
>> project. But in a mature project, consistency is more important than
>> (at best) tiny ergonomic improvements. In fact, consistency is one of
>> the most important factors contributing to ergonomy. You point out
>> that you wouldn't want to invite wholesale refactoring, but to be
>> fair, I'd rather have a wholesale refactor to use markdown comments
>> everywhere than be forever annoyed to see two wildly different comment
>> styles next to each other.
>>
>> I've looked at recent CSRs and API additions in the JDK, and haven't
>> found a single one using markdown comments. Why the rush to be the
>> first project to use them?
>>
>> In any case, if we end up allowing markdown comments, I would strongly
>> suggest to only allow a single comment style per file. Mixing both
>> styles in a single file is an unmitigated readability disaster.
>>
>>
>>
>> On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
>>  wrote:
>>> Now that JavaFX requires JDK 24 to build, we can use features from JDK
>>> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
>>> delivered in JDK 23.
>>>
>>> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
>>> proposed changes that do just that.
>>>
>>> As was pointed out in a review comment on PR 1873 [3], we should make a
>>> deliberate decision to start using them and have some guidelines around
>>> doing so.
>>>
>>> To that end, I would propose that developers can start using markdown
>>> javadoc comments in new APIs and in APIs that are modified such that
>>> markdown comments would be helpful.
>>>
>>> This is not an invitation to do wholesale changing of existing javadoc
>>> comments to markdown-style comments for docs that otherwise aren't being
>>> modified.
>>>
>>> Comments are welcome.
>>>
>>> -- Kevin
>>>
>>> [0] https://openjdk.org/jeps/467
>>> [1] https://github.com/openjdk/jfx/pull/1873
>>> [2] https://github.com/openjdk/jfx/pull/1880
>>> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kevin.rushforth at oracle.com  Wed Oct 15 16:27:24 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 15 Oct 2025 09:27:24 -0700
Subject: Using markdown-style javadoc comments (JEP 467)
In-Reply-To: 
References: <5ef9ccc6-0f9d-4d3a-9227-32d754cdb2db@oracle.com>
 
 <2c539cdf-e62e-490d-94a3-f1b8c0150312@gmail.com>
 <01b6dce5-21a4-4261-83ab-070989326942@oracle.com>
 
Message-ID: <785b8dcc-3de7-47e6-8d80-565dded99c77@oracle.com>

As a rule we don't backport new API, but we do sometimes backport 
wording changes (since we don't have the same constraints that Java SE 
spec has). So this would be another consideration in the discussion as 
to when and whether to allow using markdown.

-- Kevin


On 10/15/2025 9:20 AM, Andy Goryachev wrote:
> Another consideration is backporting. ?So, despite my earlier support 
> for markdown comments, I reverse my position and say that we should 
> avoid it for the time being.
>
> -andy
>
> *From: *openjfx-dev  on behalf of Kevin 
> Rushforth 
> *Date: *Friday, October 10, 2025 at 12:26
> *To: *openjfx-dev at openjdk.org 
> *Subject: *Re: Using markdown-style javadoc comments (JEP 467)
>
> I informally polled a few folks in the core libs group. They haven't
> started using it in the JDK yet, but would consider it primarily for new
> classes; some felt as Michael did that mixing styles in the same class
> would be annoying.
>
> I can see the argument for consistency, especially in a file like Node
> or Control, where we have many existing properties and other methods.
> For additions of a new property or method in such a file, consistency
> seems more important than being able to use markdown.
>
> In cases where there aren't so many methods, or where you are already
> modifying many of them, it might be reasonable to use markdown for new
> or modified methods.
>
> Perhaps as a compromise, we could consider allowing for new classes and
> classes where you are modifying a large percentage of the existing docs
> anyway, but in general, avoid using markdown in existing classes.
>
> Concretely, that would mean asking Nir to update PR 1873 [1] to not use
> markdown-style doc comments (it seems gratuitous there anyway, since it
> isn't using any markdown syntax), but allow the use of markdown in PR
> 1880 [2].
>
> Thoughts?
>
> -- Kevin
>
> [1] https://github.com/openjdk/jfx/pull/1873
> [2] https://github.com/openjdk/jfx/pull/1880
>
>
> On 10/7/2025 6:33 AM, John Hendrikx wrote:
> > I'm of the same mind.? I don't see a use case for markdown comments at
> > all in a
> > project as mature as JavaFX, and I'm unlikely to use them, even for new
> > files simply to be
> > more consistent with other existing files (and I may copy/paste docs
> > sometimes as well).
> >
> > There are barely any code conventions in FX as it is (indent is?4
> > spaces, and general Java naming
> > conventions are the only ones that I think of that are consistent
> > through-out the project), but
> > a consistent Javadoc?style can also be?considered one currently... 
> still.
> >
> > --John
> >
> > On 07/10/2025 10:47, Michael Strau? wrote:
> >> Markdown comments are not _better_ than HTML comments, they are just
> >> different. In particular, I question the unsubstantiated claim that
> >> markdown comments are more readable; I've never once struggled with
> >> reading HTML comments, especially if you use the recent additions like
> >> {@snippet}.
> >>
> >> I might use markdown comments myself if I were to start a greenfield
> >> project. But in a mature project, consistency is more important than
> >> (at best) tiny ergonomic improvements. In fact, consistency is one of
> >> the most important factors contributing to ergonomy. You point out
> >> that you wouldn't want to invite wholesale refactoring, but to be
> >> fair, I'd rather have a wholesale refactor to use markdown comments
> >> everywhere than be forever annoyed to see two wildly different comment
> >> styles next to each other.
> >>
> >> I've looked at recent CSRs and API additions in the JDK, and haven't
> >> found a single one using markdown comments. Why the rush to be the
> >> first project to use them?
> >>
> >> In any case, if we end up allowing markdown comments, I would strongly
> >> suggest to only allow a single comment style per file. Mixing both
> >> styles in a single file is an unmitigated readability disaster.
> >>
> >>
> >>
> >> On Thu, Oct 2, 2025 at 7:33?PM Kevin Rushforth
> >>  wrote:
> >>> Now that JavaFX requires JDK 24 to build, we can use features from JDK
> >>> 23 and 24 like markdown javadoc comments from JEP 467 [0], which was
> >>> delivered in JDK 23.
> >>>
> >>> Two outstanding pull requests, PR 1873 [1] and PR 1880 [2], have
> >>> proposed changes that do just that.
> >>>
> >>> As was pointed out in a review comment on PR 1873 [3], we should 
> make a
> >>> deliberate decision to start using them and have some guidelines 
> around
> >>> doing so.
> >>>
> >>> To that end, I would propose that developers can start using markdown
> >>> javadoc comments in new APIs and in APIs that are modified such that
> >>> markdown comments would be helpful.
> >>>
> >>> This is not an invitation to do wholesale changing of existing javadoc
> >>> comments to markdown-style comments for docs that otherwise aren't 
> being
> >>> modified.
> >>>
> >>> Comments are welcome.
> >>>
> >>> -- Kevin
> >>>
> >>> [0] https://openjdk.org/jeps/467
> >>> [1] https://github.com/openjdk/jfx/pull/1873
> >>> [2] https://github.com/openjdk/jfx/pull/1880
> >>> [3] https://github.com/openjdk/jfx/pull/1873#discussion_r2283161713
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.hendrikx at gmail.com  Wed Oct 15 16:52:45 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 15 Oct 2025 18:52:45 +0200
Subject: [External] : Re: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
 
 <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>
 
Message-ID: 

There is also the focus traversable flag that interacts with this, but
perhaps there is a bug.? When a button has focusTraversable set to
false, clicking it will not give it focus.? One may?say that a property
named "focus traversable" would only affect focus *traversal* with the
keyboard (as I'd hardly call clicking with the mouse "traversal").

That still leaves mnemonic short-cuts and default actions for buttons
though.? Pretty sure those also don't focus the button and aren't
intended to, yet do execute the action.

--John

On 15/10/2025 17:20, Andy Goryachev wrote:
>
>  *
>     Buttons are one of those (either with mouse press or keyboard
>     short cut)
>
>
> This looks like a bug to me, really. ?What is the main purpose of the
> focus subsystem?
> I know we like to reinvent the wheel, but focus in Swing works as
> expected, and one does get focus lost event on mouse press, and the
> target button gets the focus. ?Why should FX be different?
>
> -andy ?
>
>
> *From: *John Hendrikx 
> *Date: *Wednesday, October 15, 2025 at 08:05
> *To: *Marius Hanl , Andy Goryachev
> , openjfx-dev at openjdk.org
> 
> *Subject: *[External] : Re: Allowing a cell to commit the value on
> focus loss
>
> Hi Marius,
>
> Focus lost is currently sort of a proxy of starting an interaction
> with a new control, but not all controls gain focus when interacted
> with.? Buttons are one of those (either with mouse press or keyboard
> short cut), but there is I think also the scroll wheel that can
> interact with a control without focusing it (and perhaps even popup
> menu's).
>
> I can only think of one half-baked solution to this:
>
> - Have a new Event type that is always targetted at the current focus
> owner ("InterestLostEvent" ? :))
> - This event is automatically fired by Scene just before an event is
> fired that is?not targetted at the current focus owner, AND the last
> event fired did have the focus owner as target
>
> What would happen in practice then would be something like:
>
> - User edits field, keypress events go to current focus owner
> - User does something else (moves mouse, scrolls, presses a hotkey, or
> presses a button):
> ??? - An InterestLostEvent is fired at the current focus owner BEFORE
> the new event is fired
> ??? - The delayed new event is now fired
> ??? - No further InterestLostEvents are fired until the focus owner
> has received a normal event again
> - User goes back to editing after playing with the mouse; events
> targetted at the focus owner renew the interest in that control, and
> so next time an InterestLostEvent is fired again when needed
>
> It feels a bit awkward, especially because simple things like mouse
> moves may trigger it already (but a mouse move may trigger something
> that requires the model to be up to date...); perhaps it would need to
> be selective in some way so one can choose to only be interested in
> the InterestLostEvent on focus loss and mouse clicks.
>
> I can immediately see some problems as well.? Some controls I think
> allow editing without focus gain/loss at all (I think some controls
> can be edited by just scrolling the mouse wheel over them).? When
> should those controls "commit" their values...?
>
> --John
>
>
> On 15/10/2025 16:39, Marius Hanl wrote:
>
>     Hi John,
>     ?
>     you are right that there might be corner cases.?I hope that
>     we?could, what Andy suggests, find all cases and have a deeper
>     look at them.
>     We can also check whether the focus delegation API from Michael is
>     something that could help us here (but might be completely unrelated).
>     ?
>     The other options as you also mentioned,?also have their problems.
>     Even debouncing a commit on every keystroke can be unreliable if
>     the user is too fast.
>     I really hope we can make the focus loss reliable, as we then do
>     not need much of an API changes inside the Cell Framework.
>     ?
>     -- Marius
>     *Gesendet: *Montag, 13. Oktober 2025 um 19:32
>     *Von: *"Andy Goryachev" 
>     *An: *"John Hendrikx" ,
>     "openjfx-dev at openjdk.org" 
>     *Betreff: *Re: Allowing a cell to commit the value on focus loss
>     I wonder if we should find out exactly why onFocusLost does not
>     work in these cases, as expected. ?Then, if I understand the
>     proposal correctly, we won't need any API changes.
>     ?
>     -andy
>     ?
>     ?
>     ?
>     *From: *openjfx-dev ?on behalf of
>     John Hendrikx 
>     *Date: *Monday, October 13, 2025 at 07:17
>     *To: *openjfx-dev at openjdk.org 
>     *Subject: *Re: Allowing a cell to commit the value on focus loss
>
>     Hi Marius,
>
>     This may be unrelated, but it may be problematic to rely on
>     committing values using focus lost:
>
>     I've built a lot of code that relies on focus lost to "commit"
>     values to some underlying model.? However, I noticed that a focus
>     lost handler for committing values is insufficient when an action
>     is triggered that doesn't trigger a loss of focus.?? For example,
>     if I have a field "email address" and a Button "Send Email", and I
>     have a focus lost handler to commit the email address textfield to
>     an underlying model, then pressing the Button will not trigger
>     that handler and the underlying model may not have been updated
>     with the latest edits.
>
>     Solutions to trigger the correct action are all a bit tricky or
>     annoying:
>
>     - Query all fields for their current contents as focus lost is not
>     entirely reliable for this purpose
>     - Have fields update models immediately (which would be on every
>     key press...) -- this is not very efficient, and can get in the
>     way of validation / model restrictions
>     - Have controls listen to a "COMMIT" event (this is fired at the
>     current focus owner by the Button).? This event may be veto'd if
>     committing the value resulted in a validation error, in which case
>     the button press is cancelled
>
>     I don't like any of these, but using the last option at the moment
>     because I like constant updates and having to requery UI
>     components even less...
>
>     --John
>
>
>     I noticed however that if you edit some field (it doesn't have to
>     be in a table view, just a regular field), and have a focus lost
>     handler that commits the value, that this focus lost handler is
>     insufficient...
>
>     On 13/10/2025 14:53, mariushanl at web.de?wrote:
>
>         All,
>         ?
>         I created an initial poc 1* to support developers to commit
>         the cell value when the focus is lost 2* (including 3*).
>         More specifically, this gives the maximum flexibility to
>         choose what should happen when the focus is lost or the
>         editing index changed (which may happen when clicking into
>         another cell while editing).
>         All information mentioned here are also in the description of
>         the PR.
>         ?
>         *API*
>         *?*
>         - Instead of calling `/cancelEdit/`, every cell now calls
>         `/stopEdit/` when the focus is lost or the editing index
>         changed. The default behavior is cancelling the edit, but
>         developers can now override the behavior and allow a
>         `/commitEdit/` instead
>         - There are multiple 'events' that can lead to a editing
>         change. Every change will now call `/stopEdit/`.
>         It is therefore the responsibility of the developer to decide,
>         when it makes sense to actually commit the value instead of
>         cancelling it. This decision was made as the behavior is
>         manipulating the editing index, but you as a developer can as
>         well. We do not really know what intention led to e.g. a
>         change of the editing index.
>         - Every `/MOUSE_PRESSED/` shifts the focus to the cell
>         container, which is undesired in case of editing the cell. So
>         this event is now consumed.
>         - All `/TextField/` cells now commit their value (instead of
>         cancel) on focus loss
>         - `/TextField/` Escape handling was badly implemented (it was
>         never really called, as the cell container handled Escape before)
>         ?
>         *Considerations*
>
>         - I tried to make the API minimal, and without breaking
>         changes (other than the `/TextField/` cells committing their
>         values, but we may split this up)
>         - The Cell Container focus behavior is, well, weird right now.
>         That is why consuming the event is needed to better support
>         this PR. One thing we may can consider is using the
>         `/focusWithin/` property instead for all 4 Cell Containers and
>         not calling `/requestFocus/` for nearly every
>         `/MOUSE_PRESSED/` event. If we decide so, this is needs to be
>         done before merging this PR.
>         - Clicking the `/ScrollBar/` now commits/cancels the edit. I
>         checked other applications and this is very common. But
>         something I need to note here. This probably can be fixed in
>         the same way mentioned above (`/focusWithin/`)
>         - It might be hard for a developer to exactly know the cause
>         why `/stopEdit/` is called. This does not seem like a problem,
>         as e.g. for a `/TextField/`, you normally register listeners
>         for e.g. pressing the Escape key on it, so you keep full control.
>         ?
>         *Another Approach*
>
>         - Another Approach I tested could be to request the focus to a
>         cell when clicked/edited, to ensure that the focus listener is
>         ALWAYS called before another cell will reach the editing
>         state. Again, we probably need to change the focus handling to
>         e.g. use the `/focusWithin/` property. With this approach, we
>         can only call `/stopEdit` /when the focus changed (since it is
>         now called always), but not when the editing index changed.
>         ?
>         1* - https://github.com/openjdk/jfx/pull/1935
>         2* - https://bugs.openjdk.org/browse/JDK-8089514
>         3* - https://bugs.openjdk.org/browse/JDK-8089311
>         ?
>         -- Marius
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jhendrikx at openjdk.org  Wed Oct 15 17:00:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 15 Oct 2025 17:00:11 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col)
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 15:09:02 GMT, Michael Strau?  wrote:

>> I was restricting it because "set" does not allow you to add an element either when giving `size()` as the index.  I only belatedly realized that `setAll(int, int, Collection)` is violating this, and allows to add elements and so changes the list size.
>> 
>> Naming is really important, so calling the range method `setAll` then is I think a poor choice.  So the possible methods we could introduce are:
>> 
>> - `setAll(int, Collection)` and disallow it to change size; this method is a combination of `setAll(Collection)` and `set(int, T)` similar to how `addAll(int, Collection)` is a combination of `add(int, T)` and `addAll(Collection)`. 
>> - `replaceAll(int, Collection)` similar to the above, but allows adding of elements if it runs out of elements to update
>> - `replaceAll(int, int, Collection)` a proper name for `setAll(int, int, Collection)` (`splice` was also suggested in the ticket).
>> 
>> For me I'd either go with:
>> - Have `setAll(int, Collection)`
>> - Have both `setAll(int, Collection)` and `replaceAll(int, int, Collection)`
>> 
>> The `replaceAll(int, Collection)` I think does not carry its weight, and would just be confusing given that there would be a much more clear variant `replaceAll(int, int, Collection)`.
>
> * `setAll(int, Collection)` and disallow it to change size
> I think this doesn't carry its weight. It's just an explicit name for a narrow special case of a more general operation. However, if we're going to have a method with this signature, I suggest to not go for the narrow special case, but instead at least allow me to overlap the new list across the end of the existing list.
> 
> * `replaceAll(int, int, Collection)`
> We already have `List.replaceAll(UnaryOperator)`, which does something quite different (namely, replacing all elements with different elements). I think your proposed operation really is more like a `replaceRange`.

Sorry, I meant your suggestion `replace` or `replaceRange`, not `replaceAll`.  If only I could have used `replaceAll(UnaryOperator)` to do what I wanted, but it fails to tell me the index of the element it is replacing...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2433342591

From kcr at openjdk.org  Wed Oct 15 17:02:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 17:02:13 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
Message-ID: <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>

On Wed, 15 Oct 2025 15:21:52 GMT, Andy Goryachev  wrote:

>>> And what if the control uses a custom skin that is not based on the `VirtualFlow`?
>> 
>> But that can also be used against using the description from `VirtualFlow`. Right now, I would insist to not add any more details, as the rebuild implementation may change later on. 
>> 
>> Right now, we remove and add them to the viewport, but this is not really needed. What we want to achieve is that `updateItem` is called, and this way ensures that. But there are other, better and faster ways to do so. Something I might revisit at one point in the future.
>> 
>> And since the `In other words` explains why this useful, I think we are good here.
>
> I still don't know what "rebuild" means in this context.

We should be careful not to over-specify this. The "in other words" part already suggests what it does. Maybe it could be made more explicit by adding "to match the underlying data source", like this?


     * In other words, this forces the TableView to update what it is showing to
     * the user to match the underlying data source.
     * This is useful in cases where the underlying data source has
     * changed in a way that is not observed by the TableView itself.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2433348647

From kcr at openjdk.org  Wed Oct 15 17:17:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 17:17:49 GMT
Subject: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Oct 2025 14:20:17 GMT, Michael Strau?  wrote:

> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
> 
> With this in mind, there are two changes for the `HeaderBar` control:
> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
> 
> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

Reviewers: @andy-goryachev-oracle @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3407477471

From kcr at openjdk.org  Wed Oct 15 17:17:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 17:17:49 GMT
Subject: RFR: 8369836: Update HeaderBar API
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 14 Oct 2025 17:24:22 GMT, Michael Strau?  wrote:

> Considering that the "left" and "right" terminology is deeply entrenched in JavaFX, I see no advantage in trying to fight it. However, I agree that we should clearly define what left and right means in the context of RTL layouts, which is a bit different from the usual dictionary definition of left and right.

I think this is a good choice from a consistency point of view.

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3407480778

From kcr at openjdk.org  Wed Oct 15 18:13:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 18:13:12 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v60]
In-Reply-To: 
References: 
 <0gbNhRGM6PS6yZSU8bQdOkjEdUaTSFjk78yVF8rG3zM=.2f7da2e4-8749-4a88-9dcc-91552a31571f@github.com>
 
 
 
Message-ID: 

On Thu, 18 Sep 2025 09:46:16 GMT, Thiago Milczarek Sayao  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).
>
>> > 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.

@tsayao Please merge the latest master to resolve the (trivial) merge conflict with #1924

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

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

From angorya at openjdk.org  Wed Oct 15 18:18:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Oct 2025 18:18:31 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v8]
In-Reply-To: 
References: 
Message-ID: 

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

 - Merge branch 'master' into 8353599.menu.factory
 - 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
 - ... and 2 more: https://git.openjdk.org/jfx/compare/87deb200...638681d4

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/2e8848ef..638681d4

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

  Stats: 5245 lines in 216 files changed: 3543 ins; 422 del; 1280 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 andy.goryachev at oracle.com  Wed Oct 15 18:43:08 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 15 Oct 2025 18:43:08 +0000
Subject: [External] : Re: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
 
 <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>
 
 
Message-ID: 

Good point.  For these cases, I suppose, one needs to stop or cancel editing explicitly.  The actions that are being triggered without focusLost need to have additional code to find out the currently focused editor and commit the values (and deal with validation errors), but this is an application responsibility.

The question is do we get the focusLost event when clicking on a focusable button, and if not it is probably a bug.

-andy


From: John Hendrikx 
Date: Wednesday, October 15, 2025 at 09:52
To: Andy Goryachev , Marius Hanl , openjfx-dev at openjdk.org 
Subject: Re: [External] : Re: Allowing a cell to commit the value on focus loss


There is also the focus traversable flag that interacts with this, but perhaps there is a bug.  When a button has focusTraversable set to false, clicking it will not give it focus.  One may say that a property named "focus traversable" would only affect focus *traversal* with the keyboard (as I'd hardly call clicking with the mouse "traversal").

That still leaves mnemonic short-cuts and default actions for buttons though.  Pretty sure those also don't focus the button and aren't intended to, yet do execute the action.

--John

On 15/10/2025 17:20, Andy Goryachev wrote:

  *
Buttons are one of those (either with mouse press or keyboard short cut)

This looks like a bug to me, really.  What is the main purpose of the focus subsystem?
I know we like to reinvent the wheel, but focus in Swing works as expected, and one does get focus lost event on mouse press, and the target button gets the focus.  Why should FX be different?

-andy


From: John Hendrikx 
Date: Wednesday, October 15, 2025 at 08:05
To: Marius Hanl , Andy Goryachev , openjfx-dev at openjdk.org 
Subject: [External] : Re: Allowing a cell to commit the value on focus loss


Hi Marius,

Focus lost is currently sort of a proxy of starting an interaction with a new control, but not all controls gain focus when interacted with.  Buttons are one of those (either with mouse press or keyboard short cut), but there is I think also the scroll wheel that can interact with a control without focusing it (and perhaps even popup menu's).

I can only think of one half-baked solution to this:

- Have a new Event type that is always targetted at the current focus owner ("InterestLostEvent" ? :))
- This event is automatically fired by Scene just before an event is fired that is not targetted at the current focus owner, AND the last event fired did have the focus owner as target

What would happen in practice then would be something like:

- User edits field, keypress events go to current focus owner
- User does something else (moves mouse, scrolls, presses a hotkey, or presses a button):
    - An InterestLostEvent is fired at the current focus owner BEFORE the new event is fired
    - The delayed new event is now fired
    - No further InterestLostEvents are fired until the focus owner has received a normal event again
- User goes back to editing after playing with the mouse; events targetted at the focus owner renew the interest in that control, and so next time an InterestLostEvent is fired again when needed

It feels a bit awkward, especially because simple things like mouse moves may trigger it already (but a mouse move may trigger something that requires the model to be up to date...); perhaps it would need to be selective in some way so one can choose to only be interested in the InterestLostEvent on focus loss and mouse clicks.

I can immediately see some problems as well.  Some controls I think allow editing without focus gain/loss at all (I think some controls can be edited by just scrolling the mouse wheel over them).  When should those controls "commit" their values...?

--John


On 15/10/2025 16:39, Marius Hanl wrote:
Hi John,

you are right that there might be corner cases. I hope that we could, what Andy suggests, find all cases and have a deeper look at them.
We can also check whether the focus delegation API from Michael is something that could help us here (but might be completely unrelated).

The other options as you also mentioned, also have their problems. Even debouncing a commit on every keystroke can be unreliable if the user is too fast.
I really hope we can make the focus loss reliable, as we then do not need much of an API changes inside the Cell Framework.

-- Marius
Gesendet: Montag, 13. Oktober 2025 um 19:32
Von: "Andy Goryachev" 
An: "John Hendrikx" , "openjfx-dev at openjdk.org" 
Betreff: Re: Allowing a cell to commit the value on focus loss
I wonder if we should find out exactly why onFocusLost does not work in these cases, as expected.  Then, if I understand the proposal correctly, we won't need any API changes.

-andy



From: openjfx-dev  on behalf of John Hendrikx 
Date: Monday, October 13, 2025 at 07:17
To: openjfx-dev at openjdk.org 
Subject: Re: Allowing a cell to commit the value on focus loss


Hi Marius,

This may be unrelated, but it may be problematic to rely on committing values using focus lost:

I've built a lot of code that relies on focus lost to "commit" values to some underlying model.  However, I noticed that a focus lost handler for committing values is insufficient when an action is triggered that doesn't trigger a loss of focus.   For example, if I have a field "email address" and a Button "Send Email", and I have a focus lost handler to commit the email address textfield to an underlying model, then pressing the Button will not trigger that handler and the underlying model may not have been updated with the latest edits.

Solutions to trigger the correct action are all a bit tricky or annoying:

- Query all fields for their current contents as focus lost is not entirely reliable for this purpose
- Have fields update models immediately (which would be on every key press...) -- this is not very efficient, and can get in the way of validation / model restrictions
- Have controls listen to a "COMMIT" event (this is fired at the current focus owner by the Button).  This event may be veto'd if committing the value resulted in a validation error, in which case the button press is cancelled

I don't like any of these, but using the last option at the moment because I like constant updates and having to requery UI components even less...

--John

I noticed however that if you edit some field (it doesn't have to be in a table view, just a regular field), and have a focus lost handler that commits the value, that this focus lost handler is insufficient...

On 13/10/2025 14:53, mariushanl at web.de wrote:
All,

I created an initial poc 1* to support developers to commit the cell value when the focus is lost 2* (including 3*).
More specifically, this gives the maximum flexibility to choose what should happen when the focus is lost or the editing index changed (which may happen when clicking into another cell while editing).
All information mentioned here are also in the description of the PR.

API

- Instead of calling `cancelEdit`, every cell now calls `stopEdit` when the focus is lost or the editing index changed. The default behavior is cancelling the edit, but developers can now override the behavior and allow a `commitEdit` instead
- There are multiple 'events' that can lead to a editing change. Every change will now call `stopEdit`.
It is therefore the responsibility of the developer to decide, when it makes sense to actually commit the value instead of cancelling it. This decision was made as the behavior is manipulating the editing index, but you as a developer can as well. We do not really know what intention led to e.g. a change of the editing index.
- Every `MOUSE_PRESSED` shifts the focus to the cell container, which is undesired in case of editing the cell. So this event is now consumed.
- All `TextField` cells now commit their value (instead of cancel) on focus loss
- `TextField` Escape handling was badly implemented (it was never really called, as the cell container handled Escape before)

Considerations

- I tried to make the API minimal, and without breaking changes (other than the `TextField` cells committing their values, but we may split this up)
- The Cell Container focus behavior is, well, weird right now. That is why consuming the event is needed to better support this PR. One thing we may can consider is using the `focusWithin` property instead for all 4 Cell Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` event. If we decide so, this is needs to be done before merging this PR.
- Clicking the `ScrollBar` now commits/cancels the edit. I checked other applications and this is very common. But something I need to note here. This probably can be fixed in the same way mentioned above (`focusWithin`)
- It might be hard for a developer to exactly know the cause why `stopEdit` is called. This does not seem like a problem, as e.g. for a `TextField`, you normally register listeners for e.g. pressing the Escape key on it, so you keep full control.

Another Approach

- Another Approach I tested could be to request the focus to a cell when clicked/edited, to ensure that the focus listener is ALWAYS called before another cell will reach the editing state. Again, we probably need to change the focus handling to e.g. use the `focusWithin` property. With this approach, we can only call `stopEdit` when the focus changed (since it is now called always), but not when the editing index changed.

1* - https://github.com/openjdk/jfx/pull/1935
2* - https://bugs.openjdk.org/browse/JDK-8089514
3* - https://bugs.openjdk.org/browse/JDK-8089311

-- Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tsayao at openjdk.org  Wed Oct 15 18:46:20 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 15 Oct 2025 18:46:20 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v67]
In-Reply-To: 
References: 
Message-ID: 

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

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 81 commits:

 - Merge branch 'master' into 8354943
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
 - 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
 - ... and 71 more: https://git.openjdk.org/jfx/compare/38300ca6...07d1cd31

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=66
  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 mhanl at openjdk.org  Wed Oct 15 19:10:37 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 15 Oct 2025 19:10:37 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
Message-ID: 

On Wed, 15 Oct 2025 16:59:29 GMT, Kevin Rushforth  wrote:

>> I still don't know what "rebuild" means in this context.
>
> We should be careful not to over-specify this. The "in other words" part already suggests what it does. Maybe it could be made more explicit by adding "to match the underlying data source", like this?
> 
> 
>      * In other words, this forces the TableView to update what it is showing to
>      * the user to match the underlying data source.
>      * This is useful in cases where the underlying data source has
>      * changed in a way that is not observed by the TableView itself.

I like this idea.
If we want to explain what rebuild does, I would probably mention that this means the cells are updated. So maybe instead of `rebuild`, we could use something like `re-update`, maybe?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2433659381

From credmond at certak.com  Wed Oct 15 19:51:41 2025
From: credmond at certak.com (Cormac Redmond)
Date: Wed, 15 Oct 2025 20:51:41 +0100
Subject: MacAccessible substring bug?
Message-ID: 

Hi,

I have an application which a user is reporting as unusable. The below
happens, repeatedly (sent to me by the user). After calling
Dialog.showAndWait, MacAccessible is trying to use String.substring()
illegally (JFX 25).

java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for
length 1
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown
Source)
        at
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown
Source)
        at
java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
        at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
        at java.base/java.lang.String.substring(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown
Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native
Method)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown
Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown
Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown
Source)
        at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown
Source)
        at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown
Source)
        at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown
Source)
        at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown
Source)
        <...SNIPPED...>

It seems a lot like this (unfixed) issue here:
https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't
trivial in my application's case (though, I'm not sure how the error
manifests itself to the user). I cannot reproduce the issue myself.

Is this a bug and can/should this be fixed?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Wed Oct 15 20:02:51 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 15 Oct 2025 20:02:51 +0000
Subject: MacAccessible substring bug?
In-Reply-To: 
References: 
Message-ID: 

I wonder if menu's mnemonic parsing is involved.  Would it be possible to capture a screenshot of your application when this happens?

-andy

From: openjfx-dev  on behalf of Cormac Redmond 
Date: Wednesday, October 15, 2025 at 12:52
To: OpenJFX 
Subject: MacAccessible substring bug?

Hi,

I have an application which a user is reporting as unusable. The below happens, repeatedly (sent to me by the user). After calling Dialog.showAndWait, MacAccessible is trying to use String.substring() illegally (JFX 25).

java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for length 1
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
        at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
        at java.base/java.lang.String.substring(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown Source)
        <...SNIPPED...>

It seems a lot like this (unfixed) issue here: https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't trivial in my application's case (though, I'm not sure how the error manifests itself to the user). I cannot reproduce the issue myself.

Is this a bug and can/should this be fixed?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Wed Oct 15 20:58:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 20:58:39 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: 
References: 
 
 
 <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
 
 
Message-ID: 

On Thu, 14 Aug 2025 15:37:43 GMT, Martin Fox  wrote:

>> Just remove the assumeTrue call here. I'll submit the fix for JDK-8364547 in the next day or so and then these system tests will just work.
>
> BTW, it's both the minSize and maxSize tests that are failing on both Mac and Windows. It's really just easier to fix these bugs in advance of submitting this system test.

I'm still seeing failures on macOS in both the min and max tests with `StageStyle.EXTENDED` when I test using this PR + PR #1870 

Without PR 1870, I get 8 failures -- min and max for EXTENDED and min only for the other 4 styles. With PR 1870, I only get the 4 EXTENDED stage style (min and max).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2433887375

From kcr at openjdk.org  Wed Oct 15 20:58:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 20:58:41 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v67]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 15 Oct 2025 18:46:20 GMT, Thiago Milczarek Sayao  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.
>
> 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 81 commits:
> 
>  - Merge branch 'master' into 8354943
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp
>  - 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
>  - ... and 71 more: https://git.openjdk.org/jfx/compare/38300ca6...07d1cd31

tests/system/src/test/java/test/javafx/stage/SizingTest.java line 159:

> 157:     void minSize(StageStyle stageStyle) {
> 158:         // JDK-8364547
> 159:         assumeTrue(!PlatformUtil.isWindows());

I can confirm that PR #1870 fixes the underlying bug, JDK-8364547. Once that PR is integrated, merge master and then remove this `assumeTrue`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2433889944

From kcr at openjdk.org  Wed Oct 15 21:07:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 21:07:14 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

The fix looks good.

Windows: I ran `SizingTest` from PR #1789 (removing the `assumeTrue` that skips the test on Windows), and it fails for me without this fix and passes with this fix.

macOS: I ran `SizingTest` from PR #1789, and I get 8 test failures without this fix and 4 failures with this fix. The 4 failures are all using `StageStyle.EXTENDED`, which might be a different bug.

@beldenfox Can you merge in the latest master (I did when testing and there were no issues)? And can you coment on the `StageStyle.EXTENDED` failures on macOS? I think it would be fine to treat them as a separate bug unless it is easy to fix.

I'll reapprove if you make changes.

@lukostyra or @andy-goryachev-oracle Can one of you be the second reviewer?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1870#pullrequestreview-3342264723
PR Comment: https://git.openjdk.org/jfx/pull/1870#issuecomment-3408271565

From kcr at openjdk.org  Wed Oct 15 21:34:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 21:34:17 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
Message-ID: 

On Wed, 15 Oct 2025 19:07:13 GMT, Marius Hanl  wrote:

>> We should be careful not to over-specify this. The "in other words" part already suggests what it does. Maybe it could be made more explicit by adding "to match the underlying data source", like this?
>> 
>> 
>>      * In other words, this forces the TableView to update what it is showing to
>>      * the user to match the underlying data source.
>>      * This is useful in cases where the underlying data source has
>>      * changed in a way that is not observed by the TableView itself.
>
> I like this idea.
> If we want to explain what rebuild does, I would probably mention that this means the cells are updated. So maybe instead of `rebuild`, we could use something like `re-update`, maybe?

Yes, mentioning that the cells are updated is good (and is what I was trying to add). I'd stick with "rebuild" in the first sentence, though, since that is used in VirtualFlow.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2434010757

From angorya at openjdk.org  Wed Oct 15 21:39:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Oct 2025 21:39:15 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
Message-ID: 

On Wed, 15 Oct 2025 21:31:06 GMT, Kevin Rushforth  wrote:

>> I like this idea.
>> If we want to explain what rebuild does, I would probably mention that this means the cells are updated. So maybe instead of `rebuild`, we could use something like `re-update`, maybe?
>
> Yes, mentioning that the cells are updated is good (and is what I was trying to add). I'd stick with "rebuild" in the first sentence, though, since that is used in VirtualFlow.

I don't understand what "rebuild" is, **in this context**.
There is no mention of VirtualFlow here.

Discard cells and create new?  Calls `updateItem()` on them?  Something else?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2434034634

From kcr at openjdk.org  Wed Oct 15 22:01:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Oct 2025 22:01:27 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 21:36:24 GMT, Andy Goryachev  wrote:

>> Yes, mentioning that the cells are updated is good (and is what I was trying to add). I'd stick with "rebuild" in the first sentence, though, since that is used in VirtualFlow.
>
> I don't understand what "rebuild" is, **in this context**.
> There is no mention of VirtualFlow here.
> 
> Discard cells and create new?  Calls `updateItem()` on them?  Something else?

I think I see what you are getting at now. Let's take a step back.

What we want is to give the app developer enough information to know what the purpose of calling this method is, and what the effect will be. What we don't want to do is say _how_ that is done. So you are right that we shouldn't appeal to VirtualFlow since it isn't really relevant in this context. Likewise, we don't want to constrain it with implementation details.

The `refresh()` method was added by [JDK-8098085](https://bugs.openjdk.org/browse/JDK-8098085) to allow an app developer with a custom cell to say, in effect, "even if it doesn't look like anything is changed, get the contents of the cells anyway". If that's what `updateItem()` does, then yes we can say that. Otherwise, we need to find some other way to say it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2434082633

From angorya at openjdk.org  Wed Oct 15 22:04:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Oct 2025 22:04:34 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 21:58:19 GMT, Kevin Rushforth  wrote:

>> I don't understand what "rebuild" is, **in this context**.
>> There is no mention of VirtualFlow here.
>> 
>> Discard cells and create new?  Calls `updateItem()` on them?  Something else?
>
> I think I see what you are getting at now. Let's take a step back.
> 
> What we want is to give the app developer enough information to know what the purpose of calling this method is, and what the effect will be. What we don't want to do is say _how_ that is done. So you are right that we shouldn't appeal to VirtualFlow since it isn't really relevant in this context. Likewise, we don't want to constrain it with implementation details.
> 
> The `refresh()` method was added by [JDK-8098085](https://bugs.openjdk.org/browse/JDK-8098085) to allow an app developer with a custom cell to say, in effect, "even if it doesn't look like anything is changed, get the contents of the cells anyway". If that's what `updateItem()` does, then yes we can say that. Otherwise, we need to find some other way to say it.

exactly, thank you @kevinrushforth

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2434088269

From jdv at openjdk.org  Thu Oct 16 08:59:23 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 16 Oct 2025 08:59:23 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Code change looks good to me.
I have tested using test samples present in JBS issues(including the duplicates) and HelloModality and everything works fine.

But i see change in behaviour when child window doesn't move along with owner window after this update.
Bug that we are trying to solve is when window is moved to another screen but difference in behaviour is happening even when we move it within the same screen. Do we need to capture this change in behaviour through a release note?

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3409873538

From kcr at openjdk.org  Thu Oct 16 11:33:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Oct 2025 11:33:20 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

> But i see change in behaviour when child window doesn't move along with owner window after this update. ... Do we need to capture this change in behaviour through a release note?

I'm of two minds on this. On the one hand, this is platform-specific behavior that we don't (and don't ever want to) specify. We usually don't add a release note for such a change. On the other hand, a short release note might let developers know that this change isn't a bug, but is deliberate. Without a release note, there is nothing in the list of bugs fixed by this release that would give a clue as to why the behavior changed.

@andy-goryachev-oracle @arapte (and anyone else who wants to register an opinion) -- What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3410430895

From jdv at openjdk.org  Thu Oct 16 13:46:49 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 16 Oct 2025 13:46:49 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1932#pullrequestreview-3344937287

From angorya at openjdk.org  Thu Oct 16 14:29:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 16 Oct 2025 14:29:42 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

On second thought, maybe we do want a short release note is in order, to prevent people creating bugs due to behavioral difference (plus add a prominent note in the JBS description).

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3411181726

From kcr at openjdk.org  Thu Oct 16 23:52:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Oct 2025 23:52:28 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 12:20:30 GMT, Pabulaner IV  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 ran the tests today on my Mac M1 system. I left one comment inline about needing to ensure that these tests only run on macOS.

The following two tests fail consistently for me:


MacOSSystemMenuMultiWindowFXOnlySwingLast
MacOSSystemMenuMultiWindowTest


The following fail intermittently:


MacOSSystemMenuSetWithSwingTestFirst
MacOSSystemMenuJFXPanelSwingFirstTest


Also, I noticed that running all 7 tests takes over 6 minutes on my system. I tracked down the reason to the large number of calls to fork the `osascript` process.

Here is the count by test:


Test name | Number of calls
--------- | ---------------
MacOSSystemMenuJFXPanelSwingFirstTest | 253 
MacOSSystemMenuMultiWindowFXOnlySwingFirst | 241 
MacOSSystemMenuMultiWindowFXOnlySwingLast | 276 
MacOSSystemMenuMultiWindowTest | 276 
MacOSSystemMenuMultiWindowWithSwingFirstTest | 407 
MacOSSystemMenuSetWithSwingTestFirst | 466 
MacOSSystemMenuSingleWindowWithSwingFirstTest | 165 

It isn't a deal-breaker, but it would be nice to cut this down a bit if without sacrificing test coverage (e.g,. I think it's good to test with at least one sub-menu and menus with different number of items)

tests/system/src/test/java/test/com/sun/glass/ui/mac/MacOSSystemMenuTestBase.java line 60:

> 58: import static org.junit.jupiter.api.Assertions.assertFalse;
> 59: 
> 60: public class MacOSSystemMenuTestBase {

Somewhere in this base class, add a static method annotated with `@BeforeAll` that does an `assumeTrue(PlatformUtil.isMac())` to ensure that these tests don't execute on the other platforms.

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

PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3347399422
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2437779579

From mstrauss at openjdk.org  Fri Oct 17 02:22:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 17 Oct 2025 02:22:04 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
Message-ID: 

> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
> 
> With this in mind, there are two changes for the `HeaderBar` control:
> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
> 
> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.

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

  Make leftSystemInset/rightSystemInset/minSystemHeight attached properties

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1936/files
  - new: https://git.openjdk.org/jfx/pull/1936/files/137a61e7..da4d219a

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

  Stats: 369 lines in 3 files changed: 231 ins; 116 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1936.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1936/head:pull/1936

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

From mstrauss at openjdk.org  Fri Oct 17 02:53:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 17 Oct 2025 02:53:19 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 02:22:04 GMT, Michael Strau?  wrote:

>> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
>> 
>> With this in mind, there are three changes for the `HeaderBar` control:
>> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
>> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
>> 3. Make `leftSystemInset`, `rightSystemInset`, and `minSystemHeight` attached properties for `Stage`.
>> 
>> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties

There's another thing that I think will improve the `HeaderBar`API:

The `leftSystemInset`, `rightSystemInset`, and `minSystemHeight`  properties shouldn't be normal properties, but attached properties for `Stage`. If you think about it, these aren't really properties of `HeaderBar`, but properties of `Stage` that are used in the context of `HeaderBar`.

We already have an attached property of this kind: `HeaderBar.getPrefButtonHeight(Stage)`. Having the other three properties defined similarly makes the API more consistent.

It should be noted that this will be the first instance of an _observable_ attached property in JavaFX. So while regular attached properties have a getter/setter pair like this...

class HBox {
    static Insets getMargin(Node);
    static void setMargin(Node, Insets);
}


...an observable attached property will have an observable property getter:

class HeaderBar {
    static ReadOnlyObjectProperty leftSystemInsetProperty(Stage);
    static Dimension2D getLeftSystemInset(Stage);
}


The form of the property getter shouldn't be controversial, as it follows the existing getter/setter form for attached properties.

What needs to be clarified, however, is what `getBean()` and `getName()` should return for an attached observable property.
Since an attached property is a part of the object it is attached to, the `getBean()` method should return that object. In our example, this means `HeaderBar.leftSystemInsetProperty(myStage).getBean() == myStage`.

For the `getName()` method, the usual convention is to return the lowerCamelCase name of the property. However, since an attached property is not declared on the object's class to which it is attached, the name shouldn't claim that it is. I propose a naming convention of the form `DeclaringType.myProperty`, that is, the property name is qualified with the declaring type. In our example, the name of the property would be "HeaderBar.leftSystemInset" (instead of just "leftSystemInset").

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

PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3413572928

From arapte at openjdk.org  Fri Oct 17 06:19:23 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 17 Oct 2025 06:19:23 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

lgtm+..
Testing looks good, on same/single screen and with external screen.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1932#pullrequestreview-3348461596

From kcr at openjdk.org  Fri Oct 17 12:56:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Oct 2025 12:56:22 GMT
Subject: RFR: 8252373: [macOS] Stage with owner disappears when moved to
 another screen [v2]
In-Reply-To: 
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
 
Message-ID: 

On Wed, 8 Oct 2025 18:17:11 GMT, Kevin Rushforth  wrote:

>> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
>> 
>> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
>> 
>> ### Notes to reviewers:
>> 
>> The following changes are implemented:
>> 
>> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
>> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
>> * When an owner window is closed, all child windows are recursively closed.
>> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
>> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
>> 
>> Testing:
>> 
>> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
>> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
>> * MonkeyTester also has some dialog tests that can be used to verify the behavior
>> 
>> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252373-mac-dual-screen-owned-stage
>  - Remove or comment out log messages
>  - 8252373: [macOS] Stage with owner disappears when moved to another screen

Thanks for the reviews. I think I will create a short release note for it and also add a note to the JBS bug Description as Andy suggests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1932#issuecomment-3415477788

From kcr at openjdk.org  Fri Oct 17 12:56:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Oct 2025 12:56:23 GMT
Subject: Integrated: 8252373: [macOS] Stage with owner disappears when moved to
 another screen
In-Reply-To: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
References: <0DtKMIZZTzq8ozok7OFRk58rZncS1W2zDPIfKoPSk_8=.129c0737-55c9-4fa6-803f-08f71644f4f0@github.com>
Message-ID: 

On Wed, 8 Oct 2025 13:57:16 GMT, Kevin Rushforth  wrote:

> This PR fixes the bug where owned stage will disappear on macOS if it is moved to another screen with the Mission Control setting of "Displays have separate spaces" enabled (which it is by default).
> 
> We fix this by managing owned windows ourself in glass rather than relying on NSWindow's childWindow feature, which we currently do. This matches what AWT does.
> 
> ### Notes to reviewers:
> 
> The following changes are implemented:
> 
> * Each GlassWindow keeps a list of owned (child) windows. A window with an owner adds itself to its owner's list of child windows when created and removes itself when closed
> * A new `reorderChildWindows` method is created to stack each child window above its owner, setting the level to be at least the same as its owner (to handle the case of an owned window of an always-on-top owner window). We call `reorderChildWindows` in various places that can alter the window stacking order, so we can preserve the desired order.
> * When an owner window is closed, all child windows are recursively closed.
> * When an owner window is iconified / deiconified, all child windows are recursively iconified / deiconified.
> * When an owner window enters full screen, it recursively sets the `NSWindowCollectionBehaviorMoveToActiveSpace` behavior to temporarily enable moving the child window to the active space
> 
> Testing:
> 
> * Most of the testing can be done on a single screen, but you will need 2 screens to reproduce the bug by dragging an owned window from one screen to another (and verify that it is fixed)
> * You can use the updated HelloModality test app to test this. It already had most of what was needed to test the various combinations; I added the ability to create / toggle the alwaysOnTop property of a Stage and the ability to initially create a stage on a secondary screen. I also added tooltips, which are implemented using owned popup windows.
> * MonkeyTester also has some dialog tests that can be used to verify the behavior
> 
> NOTE: dragging an owner window no longer causes all child windows to move in lock step; this means that owned windows will now works more like it does on the Windows platform.

This pull request has now been integrated.

Changeset: 866f68d3
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx/commit/866f68d368594fc44241fdb61adbe522031de05e
Stats:     235 lines in 5 files changed: 207 ins; 9 del; 19 mod

8252373: [macOS] Stage with owner disappears when moved to another screen

Reviewed-by: angorya, jdv, arapte

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

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

From arapte at openjdk.org  Fri Oct 17 13:25:30 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 17 Oct 2025 13:25:30 GMT
Subject: RFR: 8369820: FX: Update copyright year in docs, readme files to 2026
Message-ID: 

Update Copyright year in the 3 doc files to 2026.

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

Commit messages:
 - doc copyright year update

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

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

From arapte at openjdk.org  Fri Oct 17 13:25:30 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 17 Oct 2025 13:25:30 GMT
Subject: RFR: 8369820: FX: Update copyright year in docs,
 readme files to 2026
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 13:19:03 GMT, Ambarish Rapte  wrote:

> Update Copyright year in the 3 doc files to 2026.

@kevinrushforth please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1939#issuecomment-3415597558

From mfox at openjdk.org  Fri Oct 17 13:30:59 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 17 Oct 2025 13:30:59 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

Thanks for the review. I'm traveling so won't be able to pick this up again until November.

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

PR Comment: https://git.openjdk.org/jfx/pull/1870#issuecomment-3415626185

From kcr at openjdk.org  Fri Oct 17 14:07:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Oct 2025 14:07:44 GMT
Subject: RFR: 8369820: FX: Update copyright year in docs,
 readme files to 2026
In-Reply-To: 
References: 
Message-ID: <6apd7z5TYacZIQv6Va7bNqFWA2i9ryFITWYHaa_80PQ=.f7f94d70-833b-4099-9fc2-e8d225662701@github.com>

On Fri, 17 Oct 2025 13:19:03 GMT, Ambarish Rapte  wrote:

> Update Copyright year in the 3 doc files to 2026.

LGTM

You can integrate without waiting for 24 hours for this simple copyright year change.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1939#pullrequestreview-3350530056

From credmond at certak.com  Fri Oct 17 15:38:23 2025
From: credmond at certak.com (Cormac Redmond)
Date: Fri, 17 Oct 2025 16:38:23 +0100
Subject: MacAccessible substring bug?
In-Reply-To: 
References: 
 
Message-ID: 

Hi,

They did follow-up to say it's happening on "every textinput", so I assume
they mean every character they enter. They tried software restarts
including their Mac Mini M2, no help..

I requested a screenshot, but the user has seemingly disappeared (it's a
first-time user of free software so there's no incentive for them to stick
around).

If anyone has a Mac Mini M2 or similar (with a clue about its accessibility
software, which might be playing a part in this), I can link you to my
software; it's straightforward to run, to see if reproducible?




Kind Regards,
Cormac

On Wed, 15 Oct 2025 at 21:02, Andy Goryachev 
wrote:

> I wonder if menu's mnemonic parsing is involved.  Would it be possible to
> capture a screenshot of your application when this happens?
>
> -andy
>
> *From: *openjfx-dev  on behalf of Cormac
> Redmond 
> *Date: *Wednesday, October 15, 2025 at 12:52
> *To: *OpenJFX 
> *Subject: *MacAccessible substring bug?
>
> Hi,
>
> I have an application which a user is reporting as unusable. The below
> happens, repeatedly (sent to me by the user). After calling
> Dialog.showAndWait, MacAccessible is trying to use String.substring()
> illegally (JFX 25).
>
> java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for
> length 1
>         at java.base/jdk.internal.util.Preconditions$1.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$1.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$4.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$4.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown
> Source)
>         at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown
> Source)
>         at
> java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
>         at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
>         at java.base/java.lang.String.substring(Unknown Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native
> Method)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown
> Source)
>         at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown
> Source)
>         at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown
> Source)
>         <...SNIPPED...>
>
> It seems a lot like this (unfixed) issue here:
> https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't
> trivial in my application's case (though, I'm not sure how the error
> manifests itself to the user). I cannot reproduce the issue myself.
>
> Is this a bug and can/should this be fixed?
>
>
>
> Kind Regards,
> Cormac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Fri Oct 17 16:25:01 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 17 Oct 2025 16:25:01 +0000
Subject: [External] : Re: MacAccessible substring bug?
In-Reply-To: 
References: 
 
 
Message-ID: 

The goal here is to find a reproducible scenario, preferably without installing any additional software.  The details are important here - that's why I asked for a screenshot since it might help us find details that are often omitted by the users (understandably).  You mentioned you cannot reproduce the issue - without the steps to reproduce we can't even file a meaningful JBS ticket (I mean we can, but it will be promptly closed as "cannot reproduce" methinks).

If you can find out the reproducible scenario, and we can reproduce it here, I'll create a JBS ticket.

Thank you
-andy


From: Cormac Redmond 
Date: Friday, October 17, 2025 at 08:38
To: Andy Goryachev 
Cc: OpenJFX 
Subject: [External] : Re: MacAccessible substring bug?

Hi,

They did follow-up to say it's happening on "every textinput", so I assume they mean every character they enter. They tried software restarts including their Mac Mini M2, no help..

I requested a screenshot, but the user has seemingly disappeared (it's a first-time user of free software so there's no incentive for them to stick around).

If anyone has a Mac Mini M2 or similar (with a clue about its accessibility software, which might be playing a part in this), I can link you to my software; it's straightforward to run, to see if reproducible?




Kind Regards,
Cormac

On Wed, 15 Oct 2025 at 21:02, Andy Goryachev > wrote:
I wonder if menu's mnemonic parsing is involved.  Would it be possible to capture a screenshot of your application when this happens?

-andy

From: openjfx-dev > on behalf of Cormac Redmond >
Date: Wednesday, October 15, 2025 at 12:52
To: OpenJFX >
Subject: MacAccessible substring bug?

Hi,

I have an application which a user is reporting as unusable. The below happens, repeatedly (sent to me by the user). After calling Dialog.showAndWait, MacAccessible is trying to use String.substring() illegally (JFX 25).

java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for length 1
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
        at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
        at java.base/java.lang.String.substring(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown Source)
        <...SNIPPED...>

It seems a lot like this (unfixed) issue here: https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't trivial in my application's case (though, I'm not sure how the error manifests itself to the user). I cannot reproduce the issue myself.

Is this a bug and can/should this be fixed?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From arapte at openjdk.org  Fri Oct 17 16:29:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 17 Oct 2025 16:29:13 GMT
Subject: Integrated: 8369820: FX: Update copyright year in docs,
 readme files to 2026
In-Reply-To: 
References: 
Message-ID: 

On Fri, 17 Oct 2025 13:19:03 GMT, Ambarish Rapte  wrote:

> Update Copyright year in the 3 doc files to 2026.

This pull request has now been integrated.

Changeset: 47d9dcc3
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx/commit/47d9dcc38a5e685a014774274f478b4205c6e397
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8369820: FX: Update copyright year in docs, readme files to 2026

Reviewed-by: kcr

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

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

From credmond at certak.com  Fri Oct 17 21:21:25 2025
From: credmond at certak.com (Cormac Redmond)
Date: Fri, 17 Oct 2025 22:21:25 +0100
Subject: [External] : Re: MacAccessible substring bug?
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Hi Andy,

I know, and I share your frustration at not being able to reproduce it.

In this case, there are already two reproducible bugs *related *to this
class in question, when VoiceOver is enabled (which comes preinstalled with
macOS, not third-party software):


   - JDK-8345536 (2019) 
   - JDK-8235989 (2024) 

VoiceOver has many settings, which may be related as to why I cannot
reproduce the exact issue described in JDK-8345536 (the
StringIndexOutOfBoundsException), which seems likely the same one my user
encountered. However, I *can* reproduce the second one (JDK-8235989) in my
application, only when VoiceOver is enabled.

Both issues are already known, logged, and reproducible.

In my case, a global uncaught exception handler catches these and displays
them to the user, which is not an uncommon pattern for a GUI (if there's an
error, we don't want it swallowed and unnoticed, especially when we don't
know what it affects). I think these are worth fixing.

It?s also worth noting that I have hundreds of unique macOS users each day,
which further suggests that the original problem may be related to less
common OS configurations or accessibility software such as VoiceOver, as
otherwise I'd get more bug reports on these...


Kind regards,
Cormac

On Fri, 17 Oct 2025 at 17:25, Andy Goryachev 
wrote:

> The goal here is to find a reproducible scenario, preferably without
> installing any additional software.  The details are important here -
> that's why I asked for a screenshot since it might help us find details
> that are often omitted by the users (understandably).  You mentioned you
> cannot reproduce the issue - without the steps to reproduce we can't even
> file a meaningful JBS ticket (I mean we can, but it will be promptly closed
> as "cannot reproduce" methinks).
>
> If you can find out the reproducible scenario, and we can reproduce it
> here, I'll create a JBS ticket.
>
> Thank you
> -andy
>
>
> *From: *Cormac Redmond 
> *Date: *Friday, October 17, 2025 at 08:38
> *To: *Andy Goryachev 
> *Cc: *OpenJFX 
> *Subject: *[External] : Re: MacAccessible substring bug?
>
> Hi,
>
> They did follow-up to say it's happening on "every textinput", so I assume
> they mean every character they enter. They tried software restarts
> including their Mac Mini M2, no help..
>
> I requested a screenshot, but the user has seemingly disappeared (it's a
> first-time user of free software so there's no incentive for them to stick
> around).
>
> If anyone has a Mac Mini M2 or similar (with a clue about its
> accessibility software, which might be playing a part in this), I can link
> you to my software; it's straightforward to run, to see if reproducible?
>
>
>
>
> Kind Regards,
> Cormac
>
> On Wed, 15 Oct 2025 at 21:02, Andy Goryachev 
> wrote:
>
> I wonder if menu's mnemonic parsing is involved.  Would it be possible to
> capture a screenshot of your application when this happens?
>
> -andy
>
> *From: *openjfx-dev  on behalf of Cormac
> Redmond 
> *Date: *Wednesday, October 15, 2025 at 12:52
> *To: *OpenJFX 
> *Subject: *MacAccessible substring bug?
>
> Hi,
>
> I have an application which a user is reporting as unusable. The below
> happens, repeatedly (sent to me by the user). After calling
> Dialog.showAndWait, MacAccessible is trying to use String.substring()
> illegally (JFX 25).
>
> java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for
> length 1
>         at java.base/jdk.internal.util.Preconditions$1.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$1.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$4.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions$4.apply(Unknown
> Source)
>         at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown
> Source)
>         at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown
> Source)
>         at
> java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
>         at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
>         at java.base/java.lang.String.substring(Unknown Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native
> Method)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown
> Source)
>         at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown
> Source)
>         at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown
> Source)
>         at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown
> Source)
>         at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown
> Source)
>         <...SNIPPED...>
>
> It seems a lot like this (unfixed) issue here:
> https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't
> trivial in my application's case (though, I'm not sure how the error
> manifests itself to the user). I cannot reproduce the issue myself.
>
> Is this a bug and can/should this be fixed?
>
>
>
> Kind Regards,
> Cormac
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From andy.goryachev at oracle.com  Fri Oct 17 21:55:44 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 17 Oct 2025 21:55:44 +0000
Subject: [External] : Re: MacAccessible substring bug?
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

Thank you!

-andy

From: Cormac Redmond 
Date: Friday, October 17, 2025 at 14:21
To: Andy Goryachev 
Cc: OpenJFX 
Subject: Re: [External] : Re: MacAccessible substring bug?


Hi Andy,

I know, and I share your frustration at not being able to reproduce it.

In this case, there are already two reproducible bugs related to this class in question, when VoiceOver is enabled (which comes preinstalled with macOS, not third-party software):

  *   JDK-8345536 (2019)
  *   JDK-8235989 (2024)

VoiceOver has many settings, which may be related as to why I cannot reproduce the exact issue described in JDK-8345536 (the StringIndexOutOfBoundsException), which seems likely the same one my user encountered. However, I can reproduce the second one (JDK-8235989) in my application, only when VoiceOver is enabled.

Both issues are already known, logged, and reproducible.

In my case, a global uncaught exception handler catches these and displays them to the user, which is not an uncommon pattern for a GUI (if there's an error, we don't want it swallowed and unnoticed, especially when we don't know what it affects). I think these are worth fixing.

It?s also worth noting that I have hundreds of unique macOS users each day, which further suggests that the original problem may be related to less common OS configurations or accessibility software such as VoiceOver, as otherwise I'd get more bug reports on these...


Kind regards,
Cormac

On Fri, 17 Oct 2025 at 17:25, Andy Goryachev > wrote:
The goal here is to find a reproducible scenario, preferably without installing any additional software.  The details are important here - that's why I asked for a screenshot since it might help us find details that are often omitted by the users (understandably).  You mentioned you cannot reproduce the issue - without the steps to reproduce we can't even file a meaningful JBS ticket (I mean we can, but it will be promptly closed as "cannot reproduce" methinks).

If you can find out the reproducible scenario, and we can reproduce it here, I'll create a JBS ticket.

Thank you
-andy


From: Cormac Redmond >
Date: Friday, October 17, 2025 at 08:38
To: Andy Goryachev >
Cc: OpenJFX >
Subject: [External] : Re: MacAccessible substring bug?

Hi,

They did follow-up to say it's happening on "every textinput", so I assume they mean every character they enter. They tried software restarts including their Mac Mini M2, no help..

I requested a screenshot, but the user has seemingly disappeared (it's a first-time user of free software so there's no incentive for them to stick around).

If anyone has a Mac Mini M2 or similar (with a clue about its accessibility software, which might be playing a part in this), I can link you to my software; it's straightforward to run, to see if reproducible?




Kind Regards,
Cormac

On Wed, 15 Oct 2025 at 21:02, Andy Goryachev > wrote:
I wonder if menu's mnemonic parsing is involved.  Would it be possible to capture a screenshot of your application when this happens?

-andy

From: openjfx-dev > on behalf of Cormac Redmond >
Date: Wednesday, October 15, 2025 at 12:52
To: OpenJFX >
Subject: MacAccessible substring bug?

Hi,

I have an application which a user is reporting as unusable. The below happens, repeatedly (sent to me by the user). After calling Dialog.showAndWait, MacAccessible is trying to use String.substring() illegally (JFX 25).

java.lang.StringIndexOutOfBoundsException: Range [1, 2) out of bounds for length 1
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$1.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions$4.apply(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Unknown Source)
        at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Unknown Source)
        at java.base/java.lang.String.checkBoundsBeginEnd(Unknown Source)
        at java.base/java.lang.String.substring(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacAccessible.accessibilityAttributeValueForParameter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoopImpl(Native Method)
        at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacApplication._enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.glass.ui.EventLoop.enter(Unknown Source)
        at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown Source)
        at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown Source)
        at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Unknown Source)
        <...SNIPPED...>

It seems a lot like this (unfixed) issue here: https://bugs.openjdk.org/browse/JDK-8235989, except the fallout isn't trivial in my application's case (though, I'm not sure how the error manifests itself to the user). I cannot reproduce the issue myself.

Is this a bug and can/should this be fixed?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Fri Oct 17 23:01:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Oct 2025 23:01:02 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 22:01:45 GMT, Andy Goryachev  wrote:

>> I think I see what you are getting at now. Let's take a step back.
>> 
>> What we want is to give the app developer enough information to know what the purpose of calling this method is, and what the effect will be. What we don't want to do is say _how_ that is done. So you are right that we shouldn't appeal to VirtualFlow since it isn't really relevant in this context. Likewise, we don't want to constrain it with implementation details.
>> 
>> The `refresh()` method was added by [JDK-8098085](https://bugs.openjdk.org/browse/JDK-8098085) to allow an app developer with a custom cell to say, in effect, "even if it doesn't look like anything is changed, get the contents of the cells anyway". If that's what `updateItem()` does, then yes we can say that. Otherwise, we need to find some other way to say it.
>
> exactly, thank you @kevinrushforth

Discussed with Kevin yesterday, what do you think of this version:

     * Calling {@code refresh()} 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.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2441415948

From angorya at openjdk.org  Fri Oct 17 23:19:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Oct 2025 23:19:53 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
Message-ID: 

Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.

Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)

For testing, one can use the updated Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest
(optionally enable IME events in stdout with Logging -> IME Monitor)

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

Commit messages:
 - test
 - accessor
 - cleanup
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8368478.ime
 - ime object
 - ime location
 - ime works
 - api

Changes: https://git.openjdk.org/jfx/pull/1938/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368478
  Stats: 577 lines in 9 files changed: 496 ins; 56 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1938.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1938/head:pull/1938

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

From kcr at openjdk.org  Sat Oct 18 13:49:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 18 Oct 2025 13:49:48 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
 
 
 
 
Message-ID: 

On Fri, 17 Oct 2025 22:57:42 GMT, Andy Goryachev  wrote:

>> exactly, thank you @kevinrushforth
>
> Discussed with Kevin yesterday, what do you think of this version:
> 
>      * Calling {@code refresh()} 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.

That looks good. You might even simplify it further and remove `Calling {@code refresh()}`, since it's redundant, and just say `Forces the XXX ...`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2442430210

From jhendrikx at openjdk.org  Mon Oct 20 05:06:20 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 20 Oct 2025 05:06:20 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col) [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
> 
> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
> 
> The other alternative is to call `set` individually for each item, which results in many change notifications.
> 
> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
> 
> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.

John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:

 - Fix test
 - Rename setAll to replaceRange and removed superfluous method

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1937/files
  - new: https://git.openjdk.org/jfx/pull/1937/files/776dd9aa..0b42426b

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

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

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

From jhendrikx at openjdk.org  Mon Oct 20 05:06:21 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 20 Oct 2025 05:06:21 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col) [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 15 Oct 2025 15:09:02 GMT, Michael Strau?  wrote:

>> I was restricting it because "set" does not allow you to add an element either when giving `size()` as the index.  I only belatedly realized that `setAll(int, int, Collection)` is violating this, and allows to add elements and so changes the list size.
>> 
>> Naming is really important, so calling the range method `setAll` then is I think a poor choice.  So the possible methods we could introduce are:
>> 
>> - `setAll(int, Collection)` and disallow it to change size; this method is a combination of `setAll(Collection)` and `set(int, T)` similar to how `addAll(int, Collection)` is a combination of `add(int, T)` and `addAll(Collection)`. 
>> - `replaceAll(int, Collection)` similar to the above, but allows adding of elements if it runs out of elements to update
>> - `replaceAll(int, int, Collection)` a proper name for `setAll(int, int, Collection)` (`splice` was also suggested in the ticket).
>> 
>> For me I'd either go with:
>> - Have `setAll(int, Collection)`
>> - Have both `setAll(int, Collection)` and `replaceAll(int, int, Collection)`
>> 
>> The `replaceAll(int, Collection)` I think does not carry its weight, and would just be confusing given that there would be a much more clear variant `replaceAll(int, int, Collection)`.
>
> * `setAll(int, Collection)` and disallow it to change size
> I think this doesn't carry its weight. It's just an explicit name for a narrow special case of a more general operation. However, if we're going to have a method with this signature, I suggest to not go for the narrow special case, but instead at least allow me to overlap the new list across the end of the existing list.
> 
> * `replaceAll(int, int, Collection)`
> We already have `List.replaceAll(UnaryOperator)`, which does something quite different (namely, replacing all elements with different elements). I think your proposed operation really is more like a `replaceRange`.

@mstr2 I was hesitant to introduce another "new" method, and was looking to only overload `setAll`, but thinking it over a bit longer, I think if we want to offer this functionality in a free form way, we may as well just introduce a `replaceRange` method.  I removed the `setAll` overload and renamed the range version to `replaceRange`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1937#discussion_r2443819424

From jhendrikx at openjdk.org  Mon Oct 20 06:26:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 20 Oct 2025 06:26:23 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx  wrote:

>> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix test
>  - Rename setAll to replaceRange and removed superfluous method

With this modification, two lists can be kept in sync with each other with this minimal code, and with minimal notifications:

    change -> {
      while(change.next()) {
        int from = change.getFrom();
        int to = change.getTo();

        if(change.wasPermutated()) {
          destination.replaceRange(from, to, change.getList().subList(from, to).stream().map(mapper).toList());
        }
        else {
          int removed = change.getRemovedSize();

          destination.replaceRange(from, from + removed, change.getList().subList(from, to).stream().map(mapper).toList());
        }
      }
    };

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3420726920

From kcr at openjdk.org  Mon Oct 20 16:47:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Oct 2025 16:47:25 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 12:20:30 GMT, Pabulaner IV  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 note that your branch is very out of date. Please merge the latest master into your branch. There is a minor merge conflict in `modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m` that you will need to resolve. Leave the commented out `NSLog` (which is present in the latest master and conflicts with your change) as the first line of the function.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3422878175

From angorya at openjdk.org  Mon Oct 20 21:51:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 20 Oct 2025 21:51:47 GMT
Subject: RFR: 8369085: RichTextArea SELECT_PARAGRAPH to include line separator
Message-ID: 

RichTextArea.Tag.SELECT_PARAGRAPH or RichTextArea.selectParagraph() must include the trailing line separator (if present).

This is a behavioral change, but a simple one (an obvious bug) - maybe one reviewer is sufficient.  I don't think this needs a CSR.

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

Commit messages:
 - select paragraph

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

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

From credmond at certak.com  Mon Oct 20 22:04:12 2025
From: credmond at certak.com (Cormac Redmond)
Date: Mon, 20 Oct 2025 23:04:12 +0100
Subject: HeaderBar & Alert/Dialog/DialogPane
Message-ID: 

Hi,

I touched on this before, but I still think there are gaps that should be
addressed with using HeaderBars and Alerts/Dialogs/DialogPanes.

There's a bunch of logic in Alert/Dialog/DialogPane regarding headerText
vs. headerNode precedence, graphic node placement, etc., which all depends
on what is set and when, etc.

To incorporate HeaderBar into Dialogs, the advice before was to "get" the
existing header node, if it's there, and set it as the center of a new
BorderPane and stick the HeaderBar as top, and set that BorderPane as the
DialogPane's header, in order to use HeaderBar. But that only partially
solves some problems, some of the time.

If you use a HeaderBar for the purpose I do: to control the color (get rid
of the ugly white bg) & to to save some precious space (i.e., get a menu
system on the left + window icons on the right) *and* want a consistent
look and feel across your application regarding popups, you must sacrifice
all of this "standard" functionality of standard Alerts/Dialogs; *or* don't
use HeaderBar for dialogs -- which looks unpolished and lacking.

Look at this example (which only touches the surface):

public class HeaderBarSupport extends Application {

    private boolean INSTALL_HEADER_BAR = true;

    @Override
    public void start(Stage primaryStage) {
        showErrorDialogHeaderText("title", "will see this", "content",
!INSTALL_HEADER_BAR); // No HeaderBar, all is fine
        showErrorDialogHeaderText("will not see this title", "will not see
this header text", "content", INSTALL_HEADER_BAR); // Won't see title,
headerText, or big red X
    }

    private void showErrorDialogHeaderText(String title, String headerText,
String content, boolean installHeaderBar) {
        Alert alert = new Alert(Alert.AlertType.ERROR, content); // Expect
error
        alert.setTitle(title);
        alert.setHeaderText(headerText);
        alert.setContentText(content);

        if (installHeaderBar) {
            installHeaderBar(alert);
        }

        alert.showAndWait();
    }

    private void installHeaderBar(final Dialog dialog) {
        Node existingHeader = dialog.getDialogPane().getHeader(); // null
in these examples
        BorderPane borderPane = new BorderPane();
        // Note: could set a label with title in the HeaderBar if desired,
but that's about as much as you can salvage
        borderPane.setTop(new HeaderBar());
        borderPane.setCenter(existingHeader);
        dialog.getDialogPane().setHeader(borderPane);
        dialog.initStyle(StageStyle.EXTENDED);
    }

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





Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From credmond at certak.com  Mon Oct 20 22:19:45 2025
From: credmond at certak.com (Cormac Redmond)
Date: Mon, 20 Oct 2025 23:19:45 +0100
Subject: HeaderBar & Alert/Dialog/DialogPane
In-Reply-To: 
References: 
Message-ID: 

I should add, it's the same problem for other standard controls
like ChoiceDialog and TextInputDialog. It's not (easily/feasibly) possible
to customise the header bar / window buttons for these dialogs either.

On Mon, 20 Oct 2025 at 23:04, Cormac Redmond  wrote:

> Hi,
>
> I touched on this before, but I still think there are gaps that should be
> addressed with using HeaderBars and Alerts/Dialogs/DialogPanes.
>
> There's a bunch of logic in Alert/Dialog/DialogPane regarding headerText
> vs. headerNode precedence, graphic node placement, etc., which all depends
> on what is set and when, etc.
>
> To incorporate HeaderBar into Dialogs, the advice before was to "get" the
> existing header node, if it's there, and set it as the center of a new
> BorderPane and stick the HeaderBar as top, and set that BorderPane as the
> DialogPane's header, in order to use HeaderBar. But that only partially
> solves some problems, some of the time.
>
> If you use a HeaderBar for the purpose I do: to control the color (get rid
> of the ugly white bg) & to to save some precious space (i.e., get a menu
> system on the left + window icons on the right) *and* want a consistent
> look and feel across your application regarding popups, you must sacrifice
> all of this "standard" functionality of standard Alerts/Dialogs; *or*
> don't use HeaderBar for dialogs -- which looks unpolished and lacking.
>
> Look at this example (which only touches the surface):
>
> public class HeaderBarSupport extends Application {
>
>     private boolean INSTALL_HEADER_BAR = true;
>
>     @Override
>     public void start(Stage primaryStage) {
>         showErrorDialogHeaderText("title", "will see this", "content",
> !INSTALL_HEADER_BAR); // No HeaderBar, all is fine
>         showErrorDialogHeaderText("will not see this title", "will not see
> this header text", "content", INSTALL_HEADER_BAR); // Won't see title,
> headerText, or big red X
>     }
>
>     private void showErrorDialogHeaderText(String title, String
> headerText, String content, boolean installHeaderBar) {
>         Alert alert = new Alert(Alert.AlertType.ERROR, content); // Expect
> error
>         alert.setTitle(title);
>         alert.setHeaderText(headerText);
>         alert.setContentText(content);
>
>         if (installHeaderBar) {
>             installHeaderBar(alert);
>         }
>
>         alert.showAndWait();
>     }
>
>     private void installHeaderBar(final Dialog dialog) {
>         Node existingHeader = dialog.getDialogPane().getHeader(); // null
> in these examples
>         BorderPane borderPane = new BorderPane();
>         // Note: could set a label with title in the HeaderBar if desired,
> but that's about as much as you can salvage
>         borderPane.setTop(new HeaderBar());
>         borderPane.setCenter(existingHeader);
>         dialog.getDialogPane().setHeader(borderPane);
>         dialog.initStyle(StageStyle.EXTENDED);
>     }
>
>     public static void main(String[] args) {
>         launch(args);
>     }
> }
>
>
>
>
>
> Kind Regards,
> Cormac
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Mon Oct 20 23:03:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Oct 2025 23:03:15 GMT
Subject: RFR: 8369085: RichTextArea SELECT_PARAGRAPH to include line
 separator
In-Reply-To: 
References: 
Message-ID: <1RqYZtQqqyurmWNtyu_ueOmJoIg_IW5iOqHU1qQtAYY=.f23e8976-7e6f-4cdc-bfc0-390c5aff071a@github.com>

On Mon, 20 Oct 2025 21:28:48 GMT, Andy Goryachev  wrote:

> RichTextArea.Tag.SELECT_PARAGRAPH or RichTextArea.selectParagraph() must include the trailing line separator (if present).
> 
> This is a behavioral change, but a simple one (an obvious bug) - maybe one reviewer is sufficient.  I don't think this needs a CSR.

I agree that this doesn't need a CSR. It seems a simple enough fix, but if @Ziad-Mid could test it that would help (or you can wait for me or @arapte to do it).

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/RichTextAreaBehavior.java line 913:

> 911:             int ix = p.index();
> 912:             TextPos an = TextPos.ofLeading(ix, 0);
> 913:             TextPos ca = TextPos.ofLeading(ix + 1, 0);

~~Will this work if you select the last paragraph in the RTA? You'll be calling `TextPos.ofLeading` with a paragraph index that is out of range, but maybe it handles it?~~

I see you added a test for just this case. Good.

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

PR Review: https://git.openjdk.org/jfx/pull/1940#pullrequestreview-3358169202
PR Review Comment: https://git.openjdk.org/jfx/pull/1940#discussion_r2446309517

From zjx001202 at gmail.com  Tue Oct 21 03:00:37 2025
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 21 Oct 2025 11:00:37 +0800
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: 
References: 
Message-ID: 

Is anyone interested in this question?

On Wed, Oct 15, 2025 at 10:21?PM Glavo  wrote:

> Hi,
>
> Our application has traditionally used StageStyle.TRANSPARENT to enable a
> fully customizable stage.
> This allows users to set custom backgrounds and adjust the window's
> opacity freely, leveraging our powerful personalization features.
>
> After the release of JavaFX 25, we want to migrate to StageStyle.EXTENDED
> so that
> we can use native window decorations and no longer need to draw window
> shadows ourselves.
> But using StageStyle.EXTENDED creates a stage with a white background,
> which prevents us
> from setting the window's opacity.
> So is there any way we can make the stage background transparent while
> using StageStyle.EXTENDED?
>
> Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dlemmermann at gmail.com  Tue Oct 21 08:09:06 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Tue, 21 Oct 2025 10:09:06 +0200
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: 
References: 
 
Message-ID: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>

I am very much interested in this, too. I currently do not need it but I had projects in the past where I wished this feature had been available. I am confident this wish will resurface again at some point in time. It?s one more of those features that will make it possible for JavaFX developers to build apps that can compete with more native UI frameworks.

Dirk

> Am 21.10.2025 um 05:00 schrieb Glavo :
> 
> Is anyone interested in this question?
> 
> On Wed, Oct 15, 2025 at 10:21?PM Glavo > wrote:
>> Hi,
>> 
>> Our application has traditionally used StageStyle.TRANSPARENT to enable a fully customizable stage. 
>> This allows users to set custom backgrounds and adjust the window's opacity freely, leveraging our powerful personalization features.
>> 
>> After the release of JavaFX 25, we want to migrate to StageStyle.EXTENDED so that 
>> we can use native window decorations and no longer need to draw window shadows ourselves.
>> But using StageStyle.EXTENDED creates a stage with a white background, which prevents us 
>> from setting the window's opacity.
>> So is there any way we can make the stage background transparent while using StageStyle.EXTENDED?
>> 
>> Glavo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Tue Oct 21 13:51:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 13:51:16 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Release notes for JavaFX 25.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=48166
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=48165
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

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

  No security content

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

Changes:
  - all: https://git.openjdk.org/jfx25u/pull/24/files
  - new: https://git.openjdk.org/jfx25u/pull/24/files/a313dbd6..c0af8db7

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

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

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

From kcr at openjdk.org  Tue Oct 21 13:51:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 13:51:18 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 13 Oct 2025 16:21:30 GMT, Andy Goryachev  wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No security content
>
> the list matches the query (sans security bugs)

@andy-goryachev-oracle Can you re-review?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/24#issuecomment-3426774806

From kcr at openjdk.org  Tue Oct 21 13:55:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 13:55:22 GMT
Subject: [jfx25u] RFR: Merge 8d54251ec726b802bcf3e1aa6c6db7e150a6ebfb
Message-ID: 

Clean merge of October CPU content into `jfx25u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

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

Commit messages:
 - Merge branch 'jfx25.0.1' into merge-jfx25.0.1
 - Merge
 - Merge
 - Merge

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

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

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

From jvos at openjdk.org  Tue Oct 21 13:56:27 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 21 Oct 2025 13:56:27 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Oct 2025 13:51:16 GMT, Kevin Rushforth  wrote:

>> Release notes for JavaFX 25.0.1.
>> 
>> Notes to reviewers:
>> 
>> I used the following filter to pick the issues:
>> 
>> https://bugs.openjdk.org/issues/?filter=48166
>> 
>> The original filter, with the backport IDs, is here:
>> 
>> https://bugs.openjdk.org/issues/?filter=48165
>> 
>> As usual, I excluded test bugs, cleanup bugs, etc.
>> 
>> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No security content

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx25u/pull/24#pullrequestreview-3360927738

From kcr at openjdk.org  Tue Oct 21 13:59:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 13:59:48 GMT
Subject: [jfx25u] Integrated: Merge 8d54251ec726b802bcf3e1aa6c6db7e150a6ebfb
In-Reply-To: 
References: 
Message-ID: <0D0OCZVNuSlJN0H2SjNrIq215qzR5E5vobrhls0tuCA=.6e86819c-ced2-4587-9c0e-76a5c0703d32@github.com>

On Tue, 21 Oct 2025 13:50:06 GMT, Kevin Rushforth  wrote:

> Clean merge of October CPU content into `jfx25u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

This pull request has now been integrated.

Changeset: d4292b45
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx25u/commit/d4292b45e786ad68dd2061b343782fad90daad19
Stats:     0 lines in 0 files changed: 0 ins; 0 del; 0 mod

Merge

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

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

From kcr at openjdk.org  Tue Oct 21 13:59:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 13:59:48 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Oct 2025 13:51:16 GMT, Kevin Rushforth  wrote:

>> Release notes for JavaFX 25.0.1.
>> 
>> Notes to reviewers:
>> 
>> I used the following filter to pick the issues:
>> 
>> https://bugs.openjdk.org/issues/?filter=48166
>> 
>> The original filter, with the backport IDs, is here:
>> 
>> https://bugs.openjdk.org/issues/?filter=48165
>> 
>> As usual, I excluded test bugs, cleanup bugs, etc.
>> 
>> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No security content

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jfx25u/pull/24#issuecomment-3426825819

From kcr at openjdk.org  Tue Oct 21 14:03:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 14:03:03 GMT
Subject: [jfx25u] Integrated: 8369610: Create release notes for JavaFX 25.0.1
In-Reply-To: 
References: 
Message-ID: <8J1WRI9lWpO2dirWXWKxTpMv6WpfG55D5c3d-iDgd_c=.42991903-022a-4a28-b132-cdf5b600f247@github.com>

On Fri, 10 Oct 2025 22:27:06 GMT, Kevin Rushforth  wrote:

> Release notes for JavaFX 25.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=48166
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=48165
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-10-21, I will add any security bugs and ask for a re-review.

This pull request has now been integrated.

Changeset: 3a6fbd2d
Author:    Kevin Rushforth 
URL:       https://git.openjdk.org/jfx25u/commit/3a6fbd2d1660c96d81653c725d90206fd732490f
Stats:     21 lines in 1 file changed: 21 ins; 0 del; 0 mod

8369610: Create release notes for JavaFX 25.0.1

Reviewed-by: jvos, angorya

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

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

From angorya at openjdk.org  Tue Oct 21 14:27:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 21 Oct 2025 14:27:59 GMT
Subject: [jfx25u] RFR: 8369610: Create release notes for JavaFX 25.0.1 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 21 Oct 2025 13:53:35 GMT, Johan Vos  wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No security content
>
> Marked as reviewed by jvos (Reviewer).

thank you @johanvos

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

PR Comment: https://git.openjdk.org/jfx25u/pull/24#issuecomment-3426961597

From angorya at openjdk.org  Tue Oct 21 16:06:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 21 Oct 2025 16:06:25 GMT
Subject: RFR: 8370253: CodeArea: NPE on copy
Message-ID: 

Fixes a missing `null` check in `CodeArea.copy()` when the `syntaxHighlighter` property is set. 

Also
- made sure other callers check for null
- removed dead code

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

Commit messages:
 - copy

Changes: https://git.openjdk.org/jfx/pull/1942/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370253
  Stats: 91 lines in 3 files changed: 70 ins; 18 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1942.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1942/head:pull/1942

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

From johan.vos at gluonhq.com  Tue Oct 21 19:42:00 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 21 Oct 2025 21:42:00 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
Message-ID: 

I recently noticed a performance degradation in a JavaFX application, that
I could trace to the fix for JDK-8360940 [1]. I believe the fix is correct,
but it can cause infinite pulses in some cases. It is somehow discussed in
the second of the 2 errors in Parent, in [2], but I believe this pattern is
used often, and will now lead to infinite pulses

For example, a class extending Parent and implementing layoutChildren that
does something like this:

@Override
protected void layoutChildren() {
    super.layoutChildren();
    if (someSpecificCondition) {
        someManagedNode.relocate(someX, someY);
    }
}

Support the someManagedNode is at (x0, y) before the pulse runs.
The call to super.layoutChildren() will set the layoutX/Y to e.g. superX,
superY and it will request a new pulse (in case superX != x0 or superY !=
y).
Next, the someManagedNode is conditionally repositioned to someX, someY .
In the next pulse (immediately following this pulse), the
super.layoutChildren will again set the layoutX/Y to superX, superY, and
trigger a new pulse, no matter what happens afterwards. The conditional
code will again reset the layoutX/Y to someX, someY (which is what they had
before this pulse started layoutChildren()), but the next pulse is
scheduled AND it will visit this Node.

Even though in the end the layoutX/layoutY properties of someManagedNode
are not changed as the result of layoutChildren, a new pulse will be
requested because there was an intermediate value (which never got
rendered, as it was changed again even before the layoutChildren returns)
that triggered the requestNextPulse.

I think this pattern is used in a number of external controls. It worked
"by accident" until the issue in JDK-8360940 was fixed. In defense of the
pattern above, one could argue that a requestPulse should only be triggered
if the triggering property was altered at the end of the layoutPhase (that
is, if there is a difference in value between the start and the end of the
layoutPhase).

In summary, I don't propose to change anything, and I agree with the commit
in [1], but it might need some attention in the release notes or docs.

- Johan


[1]
https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
[2] https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Tue Oct 21 21:29:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 21 Oct 2025 21:29:39 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter
Message-ID: 

Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.

Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
There is an internal need (`UndoableChange`), but it should not be exposed via public API.

Whenever the application needs to disable undo/redo functionality (while, for example, building a document from multiple segments), this can be accomplished by calling clearUndoRedo().

There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries (in a follow-up ticket).

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

Commit messages:
 - cleanup
 - cleanup
 - removed allow undo parameter
 - nl
 - test
 - append insert text
 - tests
 - allow undo

Changes: https://git.openjdk.org/jfx/pull/1941/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366201
  Stats: 218 lines in 16 files changed: 139 ins; 6 del; 73 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

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

From kcr at openjdk.org  Tue Oct 21 21:38:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 21:38:41 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Oct 2025 23:04:17 GMT, Andy Goryachev  wrote:

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> Whenever the application needs to disable undo/redo functionality (while, for example, building a document from multiple segments), this can be accomplished by calling clearUndoRedo().
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries (in a follow-up ticket).

This will also need a csr.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3429653520

From kcr at openjdk.org  Tue Oct 21 21:38:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 21:38:42 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 21 Oct 2025 21:35:29 GMT, Kevin Rushforth  wrote:

> This will also need a csr.

Ah, and I see you already marked it as such

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3429655211

From michaelstrau2 at gmail.com  Wed Oct 22 00:07:27 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 22 Oct 2025 02:07:27 +0200
Subject: HeaderBar & Alert/Dialog/DialogPane
In-Reply-To: 
References: 
Message-ID: 

I think we can solve this by adding the Dialog.setHeaderBar(HeaderBar) method.

If the dialog is configured to use the EXTENDED stage style, then the
implementation will internally use a BorderPane root pane with the
HeaderBar on top, and the DialogPane at its center. In all other
cases, the DialogPane is used as the root pane. This is done
automatically and transparently, so developers won't need to resort to
the trick you mentioned (get the existing header node, nest it into a
BorderPane, and set the BorderPane as the new header node).

The limitations are the same as with Stage + HeaderBar: you won't get
title text or the title icon by default; if you want it, you'll need
to provide your own.

I've prepared a PR [0], maybe you can take a look at the API and see
if this solves your use cases.

- Michael

[0] https://github.com/openjdk/jfx/pull/1943


On Tue, Oct 21, 2025 at 12:04?AM Cormac Redmond  wrote:
>
> Hi,
>
> I touched on this before, but I still think there are gaps that should be addressed with using HeaderBars and Alerts/Dialogs/DialogPanes.
>
> There's a bunch of logic in Alert/Dialog/DialogPane regarding headerText vs. headerNode precedence, graphic node placement, etc., which all depends on what is set and when, etc.
>
> To incorporate HeaderBar into Dialogs, the advice before was to "get" the existing header node, if it's there, and set it as the center of a new BorderPane and stick the HeaderBar as top, and set that BorderPane as the DialogPane's header, in order to use HeaderBar. But that only partially solves some problems, some of the time.
>
> If you use a HeaderBar for the purpose I do: to control the color (get rid of the ugly white bg) & to to save some precious space (i.e., get a menu system on the left + window icons on the right) *and* want a consistent look and feel across your application regarding popups, you must sacrifice all of this "standard" functionality of standard Alerts/Dialogs; or don't use HeaderBar for dialogs -- which looks unpolished and lacking.

From john.hendrikx at gmail.com  Wed Oct 22 02:18:50 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 22 Oct 2025 04:18:50 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: 
References: 
Message-ID: 

The code in Node that schedules a new pulse for changes to LayoutX/Y is
iffy at best IMHO.? It has a lot of guards and checks, most of which
don't really work properly.? It for example checks if the layoutX/Y is
being modified for the current layout child, but aside from
Parent#layoutChildren itself (which rarely does actual layout as its
code is overridden by real layout containers), no layout container
actually sets the current layout child before modifying the layout X/Y
of such a child.? This check therefore is effectively useless, but a
casual observer may conclude that this will ensure that a container
modifying layout X/Y will not schedule another layout (it does, but if
the calculation ends up the same, no 3rd layout is scheduled).

I'm not even entirely sure why Node bothers to do this check during a
layout pulse; position changes are expected during a layout pulse, and
if code is modifying these positions incorrectly or contrary to what the
layout container does for a managed node, then IMHO Node shouldn't
bother trying to correct this.? Your example should simply not trigger
another pulse at all, and the modification of a?managed node's position
should just be accepted.? If it ends up visually in a bad location, then
that's on this bad code changing a **managed** node.

The Layout X/Y check code seems to be intended to "correct" positions of
a managed node when the change is made outside a layout pulse, although
I have a hard time imagining when that could be (a user calling
"relocate" casually on a managed node?).? It could be via bindings (even
though it is terrible practice to bind layout properties) but then those
changes would likely propagate during a layout pulse still.

Anyway, there may still be a way to alleviate this situation.? Instead
of Node immediately scheduling a new layout, it perhaps could hook into
a "layout finished" event when it detects a Layout X/Y change.? Once
layout completes, this hook runs, checks the original X/Y versus the
latest X/Y, and only triggers another layout if they differ.? It should
be effectively the same, as the layout scheduling is already a deferred
action.? This can probably be?done with a Platform.runLater() or a pulse
listener.

Advantages of doing the above suggested modification could be:
- Reduction of unnecessary 2nd layout passes that change nothing?(but
still run a ton of complex container calculations)
- Removal of "current layout child" checks, and the associated code in
Parent (it's practically useless code anyway)
- Probably kills the need for a "force parent layout" flag in Parent as
Node can just call regular "requestLayout" as it does so now after a
layout pass completes instead of during one

The more I think of it, the more I think that this would be a far better
solution.? It however does modify core layout code, and although I think
this could be a relatively safe change, I can't guarantee that code that
has been "working around" layout issues and relying on unspecified
semantics won't be affected (just like I didn't foresee the problem you
mentioned).

--John

On 21/10/2025 21:42, Johan Vos wrote:
> I recently noticed a performance degradation in a JavaFX application,
> that I could trace to the fix for JDK-8360940 [1]. I believe the fix
> is correct, but it can cause infinite?pulses in some cases. It is
> somehow discussed in the second of the 2 errors in Parent, in [2], but
> I believe this pattern is used often, and will now lead to infinite pulses
>
> For example, a class extending Parent and implementing layoutChildren
> that does something like this:
>
> @Override
> protected void layoutChildren() {
> ? ? super.layoutChildren();
> ? ? if (someSpecificCondition) {
> ? ? ? ? someManagedNode.relocate(someX, someY);
> ? ? }
> }
>
> Support the someManagedNode is at (x0, y) before the pulse runs.
> The call to super.layoutChildren() will set the layoutX/Y to e.g.
> superX, superY and it will request a new pulse (in case superX != x0
> or superY != y).
> Next, the someManagedNode is conditionally repositioned to someX, someY .
> In the next pulse (immediately following this pulse), the
> super.layoutChildren will again set the layoutX/Y to superX, superY,
> and trigger a new pulse, no matter what happens afterwards. The
> conditional code will again reset the layoutX/Y to someX, someY (which
> is what they had before this pulse started layoutChildren()), but the
> next pulse is scheduled AND it will visit this Node.
>
> Even though in the end the layoutX/layoutY properties of
> someManagedNode are not changed as the result of layoutChildren, a new
> pulse will be requested because there was an intermediate value (which
> never got rendered, as it was changed again even before the
> layoutChildren returns) that triggered the requestNextPulse.
>
> I think this pattern is used in a number of external controls. It
> worked "by accident" until the issue in JDK-8360940 was fixed. In
> defense of the pattern above, one could argue that a requestPulse
> should only be triggered if the triggering property was altered at the
> end of the layoutPhase (that is, if there is a difference in value
> between the start and the end of the layoutPhase).
>
> In summary, I don't propose to change anything, and I agree with the
> commit in [1], but it might need some attention in the release notes
> or docs.
>
> - Johan
>
>
> [1]?https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
> [2]?https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022

From kcr at openjdk.org  Wed Oct 22 13:41:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Oct 2025 13:41:00 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Oct 2025 23:04:17 GMT, Andy Goryachev  wrote:

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> Whenever the application needs to disable undo/redo functionality (while, for example, building a document from multiple segments), this can be accomplished by calling clearUndoRedo().
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries (in a follow-up ticket).

I agree that having this as a per-method argument doesn't make sense.

I think it's worth considering a future enhancement to add a property to enable or disable the undo feature, with a default of `true`. When set to `true`, it stores entries in the undo stack and enables undo/redo. When set to `false`, it discards the current stack and doesn't store anything or allow undo/redo until the next time it is set to true.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3432416410

From duke at openjdk.org  Wed Oct 22 15:57:23 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 22 Oct 2025 15:57:23 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - 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
 - 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
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m

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

Changes: https://git.openjdk.org/jfx/pull/1904/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=04
  Stats: 1127 lines in 14 files changed: 1112 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 duke at openjdk.org  Wed Oct 22 15:59:38 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Wed, 22 Oct 2025 15:59:38 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 11 Oct 2025 12:20:30 GMT, Pabulaner IV  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 refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

I have rebased to the master and ran the tests again on another MacBook, but for me everything seems to work. Could You maybe provide me with some more information what exactly doesn't work with the tests for You?

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3433127947

From kcr at openjdk.org  Wed Oct 22 16:25:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Oct 2025 16:25:18 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Oct 2025 15:56:38 GMT, Pabulaner IV  wrote:

> I have rebased to the master

To echo what the Skara said: next time, please _merge_ master instead of rebasing to master.. Rebasing makes reviewing new change since last review difficult at best.

> for me everything seems to work. Could You maybe provide me with some more information what exactly doesn't work with the tests for You?

Sure. I'll provide the logs.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3433219198

From kcr at openjdk.org  Wed Oct 22 21:39:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Oct 2025 21:39:27 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: 
References: 
 
Message-ID: <_dkpsbk2cQrUfAWb1f2mOkC2kurRBn9Dojm9TKVKmgE=.e09e3732-dd84-4a32-b1f8-d033432cd2e3@github.com>

On Wed, 22 Oct 2025 15:57:23 GMT, Pabulaner IV  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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 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
>  - 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
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m

Here are the assertion failures for the two failing tests:


MacOSSystemMenuMultiWindowFXOnlySwingLast > test() FAILED
    org.opentest4j.AssertionFailedError: Menu size is different: 5 != 2 ==> expected:  but was: 
        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.AssertTrue.failNotTrue(AssertTrue.java:63)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)
        at app//test.com.sun.glass.ui.mac.MacOSSystemMenuTestBase.compareMenus(MacOSSystemMenuTestBase.java:350)
        at app//test.com.sun.glass.ui.mac.MacOSSystemMenuMultiWindowFXOnlySwingLast.test(MacOSSystemMenuMultiWindowFXOnlySwingLast.java:70)



MacOSSystemMenuMultiWindowTest > test() FAILED
    org.opentest4j.AssertionFailedError: Menu size is different: 5 != 2 ==> expected:  but was: 
        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.AssertTrue.failNotTrue(AssertTrue.java:63)
        at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
        at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)
        at app//test.com.sun.glass.ui.mac.MacOSSystemMenuTestBase.compareMenus(MacOSSystemMenuTestBase.java:350)
        at app//test.com.sun.glass.ui.mac.MacOSSystemMenuMultiWindowTest.test(MacOSSystemMenuMultiWindowTest.java:69)


I instrumented the code and it is picking up the menus of the Terminal app from which I ran `gradle test`. If I click on another app (e.g., the Finder) after starting `gradle` but before the test actually starts then the test passes.

I fired off a headful test on our Jenkins system and none of the tests pass. They all timeout or fail with an error from `osascript`.

All of this leads me to think that it might be better to convert these tests to manual test. Instead of using `osascript`, you could have each window show a `TextArea` with a list of what the top level menu items should be when you click in the window. What are your thoughts on this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3434284701

From kcr at openjdk.org  Wed Oct 22 21:44:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Oct 2025 21:44:54 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: 
References: 
 
Message-ID: <_3gE9PJwf1LTE7xfl-i6oXqhre0r3V_CXj-bu8U6kH0=.4f4a5704-7971-4510-b5dc-85f26cc8280b@github.com>

On Wed, 22 Oct 2025 15:57:23 GMT, Pabulaner IV  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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 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
>  - 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
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m

I left a couple comments about a (minor) merge issue.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m line 76:

> 74:     self->hostMenu = [NSApp mainMenu];
> 75: 
> 76:     //NSLog(@"windowDidBecomeKey: %p", self);

Minor merge issue: This should be the first line of this method.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m line 112:

> 110:     }
> 111: 
> 112:     //NSLog(@"windowDidResignKey: %p", self);

Minor merge issue: This should be the first line of this method.

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

PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3367628603
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2453415414
PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2453415781

From angorya at openjdk.org  Wed Oct 22 21:49:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 22 Oct 2025 21:49:04 GMT
Subject: RFR: 8370140: RichTextArea: line endings
Message-ID: 

Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.

The impacted areas are:
- saving to plain text
- copying to plain text

This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.

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

Commit messages:
 - tests
 - line endings

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370140
  Stats: 263 lines in 13 files changed: 234 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

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

From angorya at openjdk.org  Wed Oct 22 23:13:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 22 Oct 2025 23:13:36 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap
In-Reply-To: 
References: 
Message-ID: 

On Sun, 7 Sep 2025 00:12:31 GMT, Michael Strau?  wrote:

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

>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>  * map modification that would otherwise be reported as repeated invocations of the listener.
>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>  * reported with subsequent listener invocations.
>  * 

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

I'll try to finish the review this week.

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3434489670

From angorya at openjdk.org  Wed Oct 22 23:19:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 22 Oct 2025 23:19:40 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v2]
In-Reply-To: 
References: 
Message-ID: <8RiPJ6U7I7MzDpYG3gqC123-U99ahQd398hTDKw8dqo=.49ad9845-f231-408a-a2d4-a3a28a6793ea@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  undo redo enabled logic

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/4103d954..84d02951

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

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

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

From angorya at openjdk.org  Wed Oct 22 23:19:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 22 Oct 2025 23:19:41 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Oct 2025 13:38:45 GMT, Kevin Rushforth  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> I agree that having this as a per-method argument doesn't make sense.
> 
> I think it's worth considering a future enhancement to add a property to enable or disable the undo feature, with a default of `true`. When set to `true`, it stores entries in the undo stack and enables undo/redo. When set to `false`, it discards the current stack and doesn't store anything or allow undo/redo until the next time it is set to true.

Thank you @kevinrushforth for suggesting the `enableUndo` (`enableUndoRedo` ?) property.

Consider a scenario of building a (large) document programmatically: in the absence of such a property, the undo entries will be created, consuming the resources, to be immediately discarded by `clearUnoRedo()` at the end, as suggested earlier.  A better solution is to indeed explicitly disable the undo/redo via a new property.  This is especially helpful when we consider that currently the undo/redo stack has no limit - see also https://bugs.openjdk.org/browse/JDK-8370447 .

Converting this PR back to Draft to add the property, since the code is interdependent and we'll need a CSR anyway.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3433482155

From john.hendrikx at gmail.com  Thu Oct 23 00:49:21 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 23 Oct 2025 02:49:21 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: 
References: 
Message-ID: 

Johan, I had a closer look.

TLDR:?

- FX currently almost always does two layout passes, with the 2nd pass
not changing anything, due to a flaw in Node's relayout trigger logic
- I think it may be possible to fix this, and as a side effect
also?fixes your infinite layout loop scenario?

Longer version:

Although I think the original fix is correct (as it fixes broken state
tracking), I do see that the fix may cause existing flaws, that were
swept under the rug before, to become more problematic.

I think the fundamental reason for the relayout trigger code in Node on
LayoutX/Y changes is to catch cases when these are modified OUTSIDE the
scope of its direct Parent's layoutChildren call. In fact, it seemingly
does its best to detect when a change occurs as part of a Parent's
layoutChildren call as seen in this code and the clarifying comment:

// Propagate layout if this change isn't triggered by its parent

if(p != null&& !p.isCurrentLayoutChild(Node.this)) {

However, this check utterly fails in almost all situations, for the
simple reason that the child node which has its layout X/Y changed is
NOT considered the current layout child by its parent.? None of the
containers will update the current layout child before doing each
layoutX/Y change (as that would be very cumbersome...)? However, we're
not actually interested in that.? All we want to know is:?

???? *** Is this layout X/Y change performed while the direct
Parent's?layoutChildren() call is higher up in the call stack? ***

There are?two ways to answer that question:

- One can ask the *grandparent* if the child's parent is the current
layout child -> the answer would be yes, BUT?it only means?its
layout()?is running, and often also its layoutChildren() (so this isn't
perfect)
- Another option is to ask the direct parent if it is currently
performing layout -> the answer would be yes, and it normally means its
layoutChildren is running, but the flag isn't cleared immediately after
the call completes, so this is also a bit flawed; excerpt from
Parent::layout():

performingLayout= true;

layoutChildren(); ... (more code that triggers layouts for the rest of
the sub tree) ...

performingLayout= false;

The flag however is incredibly close to what we need, and an extra
tighter flag that is reset immediately after `layoutChildren` completes
(instead of after the whole subtree completes layout) would be exactly
what we need.

So now if Node wants to know if a layout X/Y is changed because the
parent's layout children triggered it, then all it needs to ask the
parent node is if this new flag is set.

With this fix, your scenario would also no longer trigger a layout loop,
assuming the node you are modifying is a direct child of the node on
which layoutChildren is overridden.

The only reason that currently this broken logic is not already
triggering infinite layouts is that a 2nd pass will set all values to
the same values, and Node will not trigger its logic if the value was
unchanged.? However, its already broken that a 2nd pass is necessary at
all.? In effect, JavaFX is currently almost?always doing **two** layout
passes; one that changes all the positions and sizes, and another that
"confirms" these unnecessarily.

As it is always dangerous to play with the layout logic, this will need
to be well tested, but I think we really need to fix this, or revert the
JDK-8360940 change as I think it may otherwise cause too much problems,
even though it is fixing problems and just exposing new ones...

--John



On 21/10/2025 21:42, Johan Vos wrote:
> I recently noticed a performance degradation in a JavaFX application,
> that I could trace to the fix for JDK-8360940 [1]. I believe the fix
> is correct, but it can cause infinite?pulses in some cases. It is
> somehow discussed in the second of the 2 errors in Parent, in [2], but
> I believe this pattern is used often, and will now lead to infinite pulses
>
> For example, a class extending Parent and implementing layoutChildren
> that does something like this:
>
> @Override
> protected void layoutChildren() {
> ? ? super.layoutChildren();
> ? ? if (someSpecificCondition) {
> ? ? ? ? someManagedNode.relocate(someX, someY);
> ? ? }
> }
>
> Support the someManagedNode is at (x0, y) before the pulse runs.
> The call to super.layoutChildren() will set the layoutX/Y to e.g.
> superX, superY and it will request a new pulse (in case superX != x0
> or superY != y).
> Next, the someManagedNode is conditionally repositioned to someX, someY .
> In the next pulse (immediately following this pulse), the
> super.layoutChildren will again set the layoutX/Y to superX, superY,
> and trigger a new pulse, no matter what happens afterwards. The
> conditional code will again reset the layoutX/Y to someX, someY (which
> is what they had before this pulse started layoutChildren()), but the
> next pulse is scheduled AND it will visit this Node.
>
> Even though in the end the layoutX/layoutY properties of
> someManagedNode are not changed as the result of layoutChildren, a new
> pulse will be requested because there was an intermediate value (which
> never got rendered, as it was changed again even before the
> layoutChildren returns) that triggered the requestNextPulse.
>
> I think this pattern is used in a number of external controls. It
> worked "by accident" until the issue in JDK-8360940 was fixed. In
> defense of the pattern above, one could argue that a requestPulse
> should only be triggered if the triggering property was altered at the
> end of the layoutPhase (that is, if there is a difference in value
> between the start and the end of the layoutPhase).
>
> In summary, I don't propose to change anything, and I agree with the
> commit in [1], but it might need some attention in the release notes
> or docs.
>
> - Johan
>
>
> [1]?https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
> [2]?https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From johan.vos at gluonhq.com  Thu Oct 23 07:16:04 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 23 Oct 2025 09:16:04 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: 
References: 
 
Message-ID: 

Hi Johan,

I didn't look in detail yet (and checked with the code), but your analysis
makes sense. I believe the root problem, though, is lack of
documentation/specs. Our knowledge is mainly based on reverse engineering
and reading the code. That allowed me to isolate and describe the "problem"
I described in my original post, but even that is far from complete, as the
layout process spans more classes and phases. I typically use pen and paper
to draw the flow for isolating issues like this, but those pictures are
never complete.
The second thing is, testing. Ideally, that should be related to specs, but
in absence of specs we can test the current situation, and mark that as the
lower bar. However, that implies that tons of tests would need to be added.
And even then, there might be fixes that in general would lead to less
pulses, but in corner cases might have a slight performance penalty.

In summary, I believe the specification part is the most important one.
That will enable rigorous testing. With the headless platform in place now,
those tests do not even require a real graphics pipeline.

- Johan

On Thu, Oct 23, 2025 at 2:49?AM John Hendrikx 
wrote:

> Johan, I had a closer look.
>
> TLDR:
>
> - FX currently almost always does two layout passes, with the 2nd pass not
> changing anything, due to a flaw in Node's relayout trigger logic
> - I think it may be possible to fix this, and as a side effect also fixes
> your infinite layout loop scenario
>
> Longer version:
>
> Although I think the original fix is correct (as it fixes broken state
> tracking), I do see that the fix may cause existing flaws, that were swept
> under the rug before, to become more problematic.
>
> I think the fundamental reason for the relayout trigger code in Node on
> LayoutX/Y changes is to catch cases when these are modified OUTSIDE the
> scope of its direct Parent's layoutChildren call. In fact, it seemingly
> does its best to detect when a change occurs as part of a Parent's
> layoutChildren call as seen in this code and the clarifying comment:
>
> // Propagate layout if this change isn't triggered by its parent
>
> if (p != null && !p.isCurrentLayoutChild(Node.this)) {
>
> However, this check utterly fails in almost all situations, for the simple
> reason that the child node which has its layout X/Y changed is NOT
> considered the current layout child by its parent.  None of the containers
> will update the current layout child before doing each layoutX/Y change (as
> that would be very cumbersome...)  However, we're not actually interested
> in that.  All we want to know is:
>
>      *** Is this layout X/Y change performed while the direct
> Parent's layoutChildren() call is higher up in the call stack? ***
>
> There are two ways to answer that question:
>
> - One can ask the *grandparent* if the child's parent is the current
> layout child -> the answer would be yes, BUT it only means its layout() is
> running, and often also its layoutChildren() (so this isn't perfect)
> - Another option is to ask the direct parent if it is currently performing
> layout -> the answer would be yes, and it normally means its layoutChildren
> is running, but the flag isn't cleared immediately after the call
> completes, so this is also a bit flawed; excerpt from Parent::layout():
>
> performingLayout = true;
>
> layoutChildren(); ... (more code that triggers layouts for the rest of the
> sub tree) ...
>
> performingLayout = false;
>
> The flag however is incredibly close to what we need, and an extra tighter
> flag that is reset immediately after `layoutChildren` completes (instead of
> after the whole subtree completes layout) would be exactly what we need.
>
> So now if Node wants to know if a layout X/Y is changed because the
> parent's layout children triggered it, then all it needs to ask the parent
> node is if this new flag is set.
>
> With this fix, your scenario would also no longer trigger a layout loop,
> assuming the node you are modifying is a direct child of the node on which
> layoutChildren is overridden.
> The only reason that currently this broken logic is not already triggering
> infinite layouts is that a 2nd pass will set all values to the same values,
> and Node will not trigger its logic if the value was unchanged.  However,
> its already broken that a 2nd pass is necessary at all.  In effect, JavaFX
> is currently almost always doing **two** layout passes; one that changes
> all the positions and sizes, and another that "confirms" these
> unnecessarily.
>
> As it is always dangerous to play with the layout logic, this will need to
> be well tested, but I think we really need to fix this, or revert the
> JDK-8360940 change as I think it may otherwise cause too much problems,
> even though it is fixing problems and just exposing new ones...
>
> --John
>
>
>
> On 21/10/2025 21:42, Johan Vos wrote:
>
> I recently noticed a performance degradation in a JavaFX application, that
> I could trace to the fix for JDK-8360940 [1]. I believe the fix is correct,
> but it can cause infinite pulses in some cases. It is somehow discussed in
> the second of the 2 errors in Parent, in [2], but I believe this pattern is
> used often, and will now lead to infinite pulses
>
> For example, a class extending Parent and implementing layoutChildren that
> does something like this:
>
> @Override
> protected void layoutChildren() {
>     super.layoutChildren();
>     if (someSpecificCondition) {
>         someManagedNode.relocate(someX, someY);
>     }
> }
>
> Support the someManagedNode is at (x0, y) before the pulse runs.
> The call to super.layoutChildren() will set the layoutX/Y to e.g. superX,
> superY and it will request a new pulse (in case superX != x0 or superY !=
> y).
> Next, the someManagedNode is conditionally repositioned to someX, someY .
> In the next pulse (immediately following this pulse), the
> super.layoutChildren will again set the layoutX/Y to superX, superY, and
> trigger a new pulse, no matter what happens afterwards. The conditional
> code will again reset the layoutX/Y to someX, someY (which is what they had
> before this pulse started layoutChildren()), but the next pulse is
> scheduled AND it will visit this Node.
>
> Even though in the end the layoutX/layoutY properties of someManagedNode
> are not changed as the result of layoutChildren, a new pulse will be
> requested because there was an intermediate value (which never got
> rendered, as it was changed again even before the layoutChildren returns)
> that triggered the requestNextPulse.
>
> I think this pattern is used in a number of external controls. It worked
> "by accident" until the issue in JDK-8360940 was fixed. In defense of the
> pattern above, one could argue that a requestPulse should only be triggered
> if the triggering property was altered at the end of the layoutPhase (that
> is, if there is a difference in value between the start and the end of the
> layoutPhase).
>
> In summary, I don't propose to change anything, and I agree with the
> commit in [1], but it might need some attention in the release notes or
> docs.
>
> - Johan
>
>
> [1]
> https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
> [2] https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lkostyra at openjdk.org  Thu Oct 23 12:47:32 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 23 Oct 2025 12:47:32 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Jul 2025 08:50:31 GMT, Lukasz Kostyra  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 didn't get a chance to look into other solutions yet, but I will be investigating that soon.

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3436732981

From john.hendrikx at gmail.com  Thu Oct 23 13:03:02 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 23 Oct 2025 15:03:02 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: 
References: 
 
 
Message-ID: <649e8fdf-dbe5-4826-a3ef-f3b2ea3b8715@gmail.com>

I did a simple experiment. I implemented the new boolean flag (I called
it `inLayoutChildren`), and have Node check that instead of checking
`isCurrentLayoutChild` which is broken.

Everything looks okay in a fairly complex application.

For non-local UI changes (when the parent box also needs to change
size), FX normally always did 2 layouts.? This becomes now one layout
pass as one would expect.? I don't notice any adverse effects here
(perhaps it feels a bit snappier now).

For local UI changes (when a control changes size, but does not affect
its parent size since it had "unused" space), FX normally does 1 layout,
and this has stayed the same.

The change is very simple and minimal, and seems to make much more
sense.? I think I'll create a PR for this so everyone can test and play
with it.

--John

On 23/10/2025 09:16, Johan Vos wrote:
> Hi Johan,
>
> I didn't look in detail yet (and checked with the code), but your
> analysis makes sense. I believe the root problem, though, is lack of
> documentation/specs. Our knowledge is mainly?based on reverse
> engineering and reading the code. That allowed me to isolate and
> describe the "problem" I described in my original post, but even that
> is far from complete, as the layout process spans more classes and
> phases. I typically use pen and paper to draw the flow for isolating
> issues like this, but those pictures are never complete.
> The second thing is, testing. Ideally, that should?be related to
> specs, but in absence?of specs we can test the current situation, and
> mark that as the lower bar. However, that implies that tons of tests
> would need to be added. And even then, there might be fixes that in
> general would lead to less pulses, but in corner cases might have a
> slight performance penalty.
>
> In summary, I believe the specification?part is the most important
> one. That will enable rigorous?testing. With the headless platform in
> place now, those tests do not even require a real graphics?pipeline.
>
> - Johan
>
> On Thu, Oct 23, 2025 at 2:49?AM John Hendrikx
>  wrote:
>
>     Johan, I had a closer look.
>
>     TLDR:?
>
>     - FX currently almost always does two layout passes, with the 2nd
>     pass not changing anything, due to a flaw in Node's relayout
>     trigger logic
>     - I think it may be possible to fix this, and as a side effect
>     also?fixes your infinite layout loop scenario?
>
>     Longer version:
>
>     Although I think the original fix is correct (as it fixes broken
>     state tracking), I do see that the fix may cause existing flaws,
>     that were swept under the rug before, to become more problematic.
>
>     I think the fundamental reason for the relayout trigger code in
>     Node on LayoutX/Y changes is to catch cases when these are
>     modified OUTSIDE the scope of its direct Parent's layoutChildren
>     call. In fact, it seemingly does its best to detect when a change
>     occurs as part of a Parent's layoutChildren call as seen in this
>     code and the clarifying comment:
>
>     // Propagate layout if this change isn't triggered by its parent
>
>     if(p != null&& !p.isCurrentLayoutChild(Node.this)) {
>
>     However, this check utterly fails in almost all situations, for
>     the simple reason that the child node which has its layout X/Y
>     changed is NOT considered the current layout child by its parent.?
>     None of the containers will update the current layout child before
>     doing each layoutX/Y change (as that would be very cumbersome...)?
>     However, we're not actually interested in that.? All we want to
>     know is:?
>
>     ???? *** Is this layout X/Y change performed while the direct
>     Parent's?layoutChildren() call is higher up in the call stack? ***
>
>     There are?two ways to answer that question:
>
>     - One can ask the *grandparent* if the child's parent is the
>     current layout child -> the answer would be yes, BUT?it only
>     means?its layout()?is running, and often also its layoutChildren()
>     (so this isn't perfect)
>     - Another option is to ask the direct parent if it is currently
>     performing layout -> the answer would be yes, and it normally
>     means its layoutChildren is running, but the flag isn't cleared
>     immediately after the call completes, so this is also a bit
>     flawed; excerpt from Parent::layout():
>
>     performingLayout= true;
>
>     layoutChildren(); ... (more code that triggers layouts for the
>     rest of the sub tree) ...
>
>     performingLayout= false;
>
>     The flag however is incredibly close to what we need, and an extra
>     tighter flag that is reset immediately after `layoutChildren`
>     completes (instead of after the whole subtree completes layout)
>     would be exactly what we need.
>
>     So now if Node wants to know if a layout X/Y is changed because
>     the parent's layout children triggered it, then all it needs to
>     ask the parent node is if this new flag is set.
>
>     With this fix, your scenario would also no longer trigger a layout
>     loop, assuming the node you are modifying is a direct child of the
>     node on which layoutChildren is overridden.
>
>     The only reason that currently this broken logic is not already
>     triggering infinite layouts is that a 2nd pass will set all values
>     to the same values, and Node will not trigger its logic if the
>     value was unchanged.? However, its already broken that a 2nd pass
>     is necessary at all.? In effect, JavaFX is currently almost?always
>     doing **two** layout passes; one that changes all the positions
>     and sizes, and another that "confirms" these unnecessarily.
>
>     As it is always dangerous to play with the layout logic, this will
>     need to be well tested, but I think we really need to fix this, or
>     revert the JDK-8360940 change as I think it may otherwise cause
>     too much problems, even though it is fixing problems and just
>     exposing new ones...
>
>     --John
>
>
>
>     On 21/10/2025 21:42, Johan Vos wrote:
>>     I recently noticed a performance degradation in a JavaFX
>>     application, that I could trace to the fix for JDK-8360940 [1]. I
>>     believe the fix is correct, but it can cause infinite?pulses in
>>     some cases. It is somehow discussed in the second of the 2 errors
>>     in Parent, in [2], but I believe this pattern is used often, and
>>     will now lead to infinite pulses
>>
>>     For example, a class extending Parent and implementing
>>     layoutChildren that does something like this:
>>
>>     @Override
>>     protected void layoutChildren() {
>>     ? ? super.layoutChildren();
>>     ? ? if (someSpecificCondition) {
>>     ? ? ? ? someManagedNode.relocate(someX, someY);
>>     ? ? }
>>     }
>>
>>     Support the someManagedNode is at (x0, y) before the pulse runs.
>>     The call to super.layoutChildren() will set the layoutX/Y to e.g.
>>     superX, superY and it will request a new pulse (in case superX !=
>>     x0 or superY != y).
>>     Next, the someManagedNode is conditionally repositioned to someX,
>>     someY .
>>     In the next pulse (immediately following this pulse), the
>>     super.layoutChildren will again set the layoutX/Y to superX,
>>     superY, and trigger a new pulse, no matter what happens
>>     afterwards. The conditional code will again reset the layoutX/Y
>>     to someX, someY (which is what they had before this pulse started
>>     layoutChildren()), but the next pulse is scheduled AND it will
>>     visit this Node.
>>
>>     Even though in the end the layoutX/layoutY properties of
>>     someManagedNode are not changed as the result of layoutChildren,
>>     a new pulse will be requested because there was an intermediate
>>     value (which never got rendered, as it was changed again even
>>     before the layoutChildren returns) that triggered the
>>     requestNextPulse.
>>
>>     I think this pattern is used in a number of external controls. It
>>     worked "by accident" until the issue in JDK-8360940 was fixed. In
>>     defense of the pattern above, one could argue that a requestPulse
>>     should only be triggered if the triggering property was altered
>>     at the end of the layoutPhase (that is, if there is a difference
>>     in value between the start and the end of the layoutPhase).
>>
>>     In summary, I don't propose to change anything, and I agree with
>>     the commit in [1], but it might need some attention in the
>>     release notes or docs.
>>
>>     - Johan
>>
>>
>>     [1]?https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
>>     [2]?https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jhendrikx at openjdk.org  Thu Oct 23 13:51:39 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 23 Oct 2025 13:51:39 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
Message-ID: 

This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

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

Commit messages:
 - Change how Node detects whether a relayout is required

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

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

From jhendrikx at openjdk.org  Thu Oct 23 13:51:40 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 23 Oct 2025 13:51:40 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Oct 2025 13:28:44 GMT, John Hendrikx  wrote:

> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

It looks like there is one failing test for ToolBarSkin.  Likely there is something relying on the superfluous 2nd layout.  I'm looking into it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3437125900

From kcr at openjdk.org  Thu Oct 23 15:55:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 15:55:55 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
Message-ID: 

On Thu, 23 Oct 2025 13:28:44 GMT, John Hendrikx  wrote:

> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

Reviewers: @johanvos @kevinrushforth @arapte

We will need a unit test for this. What is the risk of regression? Are there additional tests that we could add to help detect any regressions?

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3437778856

From kevin.rushforth at oracle.com  Thu Oct 23 16:00:30 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 23 Oct 2025 09:00:30 -0700
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: 
References: 
 
 
Message-ID: <58f92e2d-f9ec-4643-b46a-c49ff6843730@oracle.com>

Regarding the specification, are you primarily thinking about the need 
to document the implementation of layout or do you think additional 
documentation for the public / protected layout methods (e.g., 
layoutChildren) or class docs would be useful?

Regarding testing, I can see the need for additional tests. In most 
cases, layout tests can be done using unit tests in the javafx.graphics 
module. These tests use the StubToolkit (instead of the actual 
QuantumToolkit), so glass and prism are not even loaded.

Unrelated to layout or any particular test, switching the 
javafx.graphics and javafx.controls test from StubToolkit to 
QuantumToolkit + headless glass would be an interesting thing to look 
at. This might a a good discussion to split into its own thread. I can 
definitely see some value in doing this.

-- Kevin

On 10/23/2025 12:16 AM, Johan Vos wrote:
> Hi Johan,
>
> I didn't look in detail yet (and checked with the code), but your 
> analysis makes sense. I believe the root problem, though, is lack of 
> documentation/specs. Our knowledge is mainly?based on reverse 
> engineering and reading the code. That allowed me to isolate and 
> describe the "problem" I described in my original post, but even that 
> is far from complete, as the layout process spans more classes and 
> phases. I typically use pen and paper to draw the flow for isolating 
> issues like this, but those pictures are never complete.
> The second thing is, testing. Ideally, that should?be related to 
> specs, but in absence?of specs we can test the current situation, and 
> mark that as the lower bar. However, that implies that tons of tests 
> would need to be added. And even then, there might be fixes that in 
> general would lead to less pulses, but in corner cases might have a 
> slight performance penalty.
>
> In summary, I believe the specification?part is the most important 
> one. That will enable rigorous?testing. With the headless platform in 
> place now, those tests do not even require a real graphics?pipeline.
>
> - Johan
>
> On Thu, Oct 23, 2025 at 2:49?AM John Hendrikx 
>  wrote:
>
>     Johan, I had a closer look.
>
>     TLDR:
>
>     - FX currently almost always does two layout passes, with the 2nd
>     pass not changing anything, due to a flaw in Node's relayout
>     trigger logic
>     - I think it may be possible to fix this, and as a side effect
>     also?fixes your infinite layout loop scenario
>
>     Longer version:
>
>     Although I think the original fix is correct (as it fixes broken
>     state tracking), I do see that the fix may cause existing flaws,
>     that were swept under the rug before, to become more problematic.
>
>     I think the fundamental reason for the relayout trigger code in
>     Node on LayoutX/Y changes is to catch cases when these are
>     modified OUTSIDE the scope of its direct Parent's layoutChildren
>     call. In fact, it seemingly does its best to detect when a change
>     occurs as part of a Parent's layoutChildren call as seen in this
>     code and the clarifying comment:
>
>     // Propagate layout if this change isn't triggered by its parent
>
>     if(p != null&& !p.isCurrentLayoutChild(Node.this)) {
>
>     However, this check utterly fails in almost all situations, for
>     the simple reason that the child node which has its layout X/Y
>     changed is NOT considered the current layout child by its parent.?
>     None of the containers will update the current layout child before
>     doing each layoutX/Y change (as that would be very cumbersome...)?
>     However, we're not actually interested in that.? All we want to
>     know is:
>
>     ???? *** Is this layout X/Y change performed while the direct
>     Parent's?layoutChildren() call is higher up in the call stack? ***
>
>     There are?two ways to answer that question:
>
>     - One can ask the *grandparent* if the child's parent is the
>     current layout child -> the answer would be yes, BUT?it only
>     means?its layout()?is running, and often also its layoutChildren()
>     (so this isn't perfect)
>     - Another option is to ask the direct parent if it is currently
>     performing layout -> the answer would be yes, and it normally
>     means its layoutChildren is running, but the flag isn't cleared
>     immediately after the call completes, so this is also a bit
>     flawed; excerpt from Parent::layout():
>
>     performingLayout= true;
>
>     layoutChildren(); ... (more code that triggers layouts for the
>     rest of the sub tree) ...
>
>     performingLayout= false;
>
>     The flag however is incredibly close to what we need, and an extra
>     tighter flag that is reset immediately after `layoutChildren`
>     completes (instead of after the whole subtree completes layout)
>     would be exactly what we need.
>
>     So now if Node wants to know if a layout X/Y is changed because
>     the parent's layout children triggered it, then all it needs to
>     ask the parent node is if this new flag is set.
>
>     With this fix, your scenario would also no longer trigger a layout
>     loop, assuming the node you are modifying is a direct child of the
>     node on which layoutChildren is overridden.
>
>     The only reason that currently this broken logic is not already
>     triggering infinite layouts is that a 2nd pass will set all values
>     to the same values, and Node will not trigger its logic if the
>     value was unchanged.? However, its already broken that a 2nd pass
>     is necessary at all.? In effect, JavaFX is currently almost?always
>     doing **two** layout passes; one that changes all the positions
>     and sizes, and another that "confirms" these unnecessarily.
>
>     As it is always dangerous to play with the layout logic, this will
>     need to be well tested, but I think we really need to fix this, or
>     revert the JDK-8360940 change as I think it may otherwise cause
>     too much problems, even though it is fixing problems and just
>     exposing new ones...
>
>     --John
>
>
>
>     On 21/10/2025 21:42, Johan Vos wrote:
>>     I recently noticed a performance degradation in a JavaFX
>>     application, that I could trace to the fix for JDK-8360940 [1]. I
>>     believe the fix is correct, but it can cause infinite?pulses in
>>     some cases. It is somehow discussed in the second of the 2 errors
>>     in Parent, in [2], but I believe this pattern is used often, and
>>     will now lead to infinite pulses
>>
>>     For example, a class extending Parent and implementing
>>     layoutChildren that does something like this:
>>
>>     @Override
>>     protected void layoutChildren() {
>>     ? ? super.layoutChildren();
>>     ? ? if (someSpecificCondition) {
>>     ? ? ? ? someManagedNode.relocate(someX, someY);
>>     ? ? }
>>     }
>>
>>     Support the someManagedNode is at (x0, y) before the pulse runs.
>>     The call to super.layoutChildren() will set the layoutX/Y to e.g.
>>     superX, superY and it will request a new pulse (in case superX !=
>>     x0 or superY != y).
>>     Next, the someManagedNode is conditionally repositioned to someX,
>>     someY .
>>     In the next pulse (immediately following this pulse), the
>>     super.layoutChildren will again set the layoutX/Y to superX,
>>     superY, and trigger a new pulse, no matter what happens
>>     afterwards. The conditional code will again reset the layoutX/Y
>>     to someX, someY (which is what they had before this pulse started
>>     layoutChildren()), but the next pulse is scheduled AND it will
>>     visit this Node.
>>
>>     Even though in the end the layoutX/layoutY properties of
>>     someManagedNode are not changed as the result of layoutChildren,
>>     a new pulse will be requested because there was an intermediate
>>     value (which never got rendered, as it was changed again even
>>     before the layoutChildren returns) that triggered the
>>     requestNextPulse.
>>
>>     I think this pattern is used in a number of external controls. It
>>     worked "by accident" until the issue in JDK-8360940 was fixed. In
>>     defense of the pattern above, one could argue that a requestPulse
>>     should only be triggered if the triggering property was altered
>>     at the end of the layoutPhase (that is, if there is a difference
>>     in value between the start and the end of the layoutPhase).
>>
>>     In summary, I don't propose to change anything, and I agree with
>>     the commit in [1], but it might need some attention in the
>>     release notes or docs.
>>
>>     - Johan
>>
>>
>>     [1]
>>     https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
>>     [2] https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Thu Oct 23 16:17:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 16:17:08 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap
In-Reply-To: 
References: 
Message-ID: 

On Sun, 7 Sep 2025 00:12:31 GMT, Michael Strau?  wrote:

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

>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>  * map modification that would otherwise be reported as repeated invocations of the listener.
>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>  * reported with subsequent listener invocations.
>  * 

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

Before going into a full review, I'd like t ask this:
1. please enumerate all the bulk methods in `Map` and `Set` that support the new behavior in the description and possibly in the javadoc
2. do we have tests that cover all the bulk methods, exercising the following three scenarios:
- `next()` is not called, received all changes individually (probably so, as it is the current behavior)
- partial retrieval scenario where the remaining changes are received via individual events as described in javadoc and the description
- all changes received via the new methods

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3437897119

From kcr at openjdk.org  Thu Oct 23 16:22:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 16:22:03 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
Message-ID: 

On Wed, 15 Oct 2025 19:07:13 GMT, Marius Hanl  wrote:

>> We should be careful not to over-specify this. The "in other words" part already suggests what it does. Maybe it could be made more explicit by adding "to match the underlying data source", like this?
>> 
>> 
>>      * In other words, this forces the TableView to update what it is showing to
>>      * the user to match the underlying data source.
>>      * This is useful in cases where the underlying data source has
>>      * changed in a way that is not observed by the TableView itself.
>
> I like this idea.
> If we want to explain what rebuild does, I would probably mention that this means the cells are updated. So maybe instead of `rebuild`, we could use something like `re-update`, maybe?

@Maran23 Can you update the javadoc for the four methods as Andy suggested above (possibly with my simplification) and then update the CSR Specification section to match? I think that's the only remaining thing needed to move this forward.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2455868260

From mstrauss at openjdk.org  Thu Oct 23 16:27:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 16:27:23 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
Message-ID: 

Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

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

Commit messages:
 - document/verify preview feature
 - Ensure that DialogPane is always attached to Scene
 - Lazily initialize Dialog.headerBar
 - Support dialogs with StageStyle.EXTENDED

Changes: https://git.openjdk.org/jfx/pull/1943/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1943&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370446
  Stats: 158 lines in 4 files changed: 135 ins; 13 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1943.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1943/head:pull/1943

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

From duke at openjdk.org  Thu Oct 23 16:27:24 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 23 Oct 2025 16:27:24 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

The nature of when and how DialogPane's "scene" is available seems to have changed.

For example, consider this (very old) code of mine:


public class BaseDialog extends Dialog implements CtDialog {

    protected BaseDialog() {
        getDialogPane().getScene().setOnKeyPressed(event -> {
            <...SNIP....>


Now I get an NPE because getScene() is null even after a dialog pane is set, presumably because of the changes to HeavyweightDialog.setDialogPane().

It might be incorrect to _assume_ a scene is assigned at this point (...?), but it is and has been for a long time...

E.g., simply instantiating a Dialog would have created a scene immediately via setDialogPane() previously:


    public Dialog() {
        this.setDialogPane(new DialogPane());
        this.initModality(Modality.APPLICATION_MODAL);
    }


... which is now not the case. Would you consider this a breaking change?

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3434400215

From mstrauss at openjdk.org  Thu Oct 23 16:27:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 16:27:25 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Oct 2025 22:25:22 GMT, Cormac Redmond  wrote:

> ...
> ... which is now not the case. Would you consider this a breaking change?

Yes, and it's probably not useful to introduce a breaking change at this point. I've updated the PR to match the old behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3434589589

From angorya at openjdk.org  Thu Oct 23 16:27:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 16:27:26 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: <45GF-c6czO6AsLLq5Z35lEHbX9aDWPXsHAbWM9h05rk=.63212be3-706e-4afb-b1c4-124843fa6047@github.com>

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java line 593:

> 591:      * @since 26
> 592:      */
> 593:     private final ObjectProperty headerBar = new SimpleObjectProperty<>(this, "headerBar") {

This property should be lazily initialized (I know it's just a draft POC)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2452488407

From duke at openjdk.org  Thu Oct 23 16:27:25 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 23 Oct 2025 16:27:25 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 22 Oct 2025 23:56:06 GMT, Michael Strau?  wrote:

> > ...
> > ... which is now not the case. Would you consider this a breaking change?
> 
> Yes, and it's probably not useful to introduce a breaking change at this point. I've updated the PR to match the old behavior.

Great, thanks. It now appears to be working as desired with these tweaks...

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3435573505

From kcr at openjdk.org  Thu Oct 23 16:27:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 16:27:27 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java line 594:

> 592:      * @since 26
> 593:      */
> 594:     private ObjectProperty headerBar;

Since this is a preview feature, it needs to be documented and handled as such.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2455576341

From mstrauss at openjdk.org  Thu Oct 23 16:27:27 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 16:27:27 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 15:18:41 GMT, Kevin Rushforth  wrote:

>> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Dialog.java line 594:
> 
>> 592:      * @since 26
>> 593:      */
>> 594:     private ObjectProperty headerBar;
> 
> Since this is a preview feature, it needs to be documented and handled as such.

Good point. This requires documenting all property methods individually, instead of relying on the javadoc tool to do it automatically (as the `@deprecated` annotation is not carried over). I'll revert this to a property field doc once this feature is finalized.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1943#discussion_r2455894309

From kcr at openjdk.org  Thu Oct 23 16:36:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 16:36:15 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: <-DXCI3vRQLnATRK3Ul46cdHQovQAOx34JDY6FIx0r5s=.c6c89afe-9f55-4b05-91d6-42329ad7b3ae@github.com>

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

@lukostyra Can you also review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3437987966

From jhendrikx at openjdk.org  Thu Oct 23 16:55:32 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 23 Oct 2025 16:55:32 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
Message-ID: 

> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

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

  Fix ToolBarSkinTest
  
  Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1945/files
  - new: https://git.openjdk.org/jfx/pull/1945/files/19246b63..a22ce090

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

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

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

From mstrauss at openjdk.org  Thu Oct 23 17:03:25 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 17:03:25 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:14:12 GMT, Andy Goryachev  wrote:

> Before going into a full review, I'd like t ask this:
> 
> 1. please enumerate all the bulk methods in `Map` and `Set` that support the new behavior in the description and possibly in the javadoc

`ObservableSetWrapper` and `ObservableMapWarpper` support bulk change notifications for all bulk operations. Since these classes aren't public API, the only place where we could document this for users is in `FXCollections.observableSet()` and `FXCollections.observableMap()`. I wonder if we want to document it explicitly, since it is supported in the entire framework by default. The only specification surface is then the new method on `SetChangeListener.Change` and `MapChangeListener.Change`.

> 2. do we have tests that cover all the bulk methods, exercising the following three scenarios:
> 
> * `next()` is not called, received all changes individually (probably so, as it is the current behavior)

The bulk operation tests are excercised both for bulk retrieval and individual retrieval. See `ObservableSetWrapperTest.TestObservableSetWrapper`.

> * partial retrieval scenario where the remaining changes are received via individual events as described in javadoc and the description

`ObservableSetWrapper.partialChangeIterationCausesSubsequentListenerInvocation`

> * all changes received via the new methods

Yes, see above.

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3438114792

From kcr at openjdk.org  Thu Oct 23 17:10:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 17:10:15 GMT
Subject: RFR: 8369085: RichTextArea SELECT_PARAGRAPH to include line
 separator
In-Reply-To: 
References: 
Message-ID: <85L2qjKKcJ1A6iBbsnQ6yCXETgFfnll4BVKm8Uj-NhY=.462ee970-5524-4baf-93a7-db3871ba2236@github.com>

On Mon, 20 Oct 2025 21:28:48 GMT, Andy Goryachev  wrote:

> RichTextArea.Tag.SELECT_PARAGRAPH or RichTextArea.selectParagraph() must include the trailing line separator (if present).
> 
> This is a behavioral change, but a simple one (an obvious bug) - maybe one reviewer is sufficient.  I don't think this needs a CSR.
> 
> Some interdependency exists between this PR and #1944.  
> Depending which gets integrated first, changes in tests will be needed.

LGTM. The newly added test fails without the fix and passes with the fix. Also, it does what I expect in MonkeyTester.

This is a simple enough fix that a single reviewer is sufficient.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1940#pullrequestreview-3371291909
PR Comment: https://git.openjdk.org/jfx/pull/1940#issuecomment-3438149735

From jhendrikx at openjdk.org  Thu Oct 23 17:10:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 23 Oct 2025 17:10:15 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

`ToolBarSkinTest` failed due to a combination of using the StubToolkit (which doesn't run pulses) and the reuse of the `ToolBar` node in several different stages (which somehow is allowed without warning).  I've modified the test so that it still detects the original problem that it intended to fix (I reverted the fix for https://bugs.openjdk.org/browse/JDK-8364049 and checked that the rewritten test still fails without the fix).

The rewritten test works without problem with this fix, and also without this fix.

The reason why the test failed is because the size cache in `Parent` was re-used between tests. Before this PR, the test would do this:
- Creates a Stage with a reusable ToolBar
- Shows the stage (this triggers a layout, it's not because of a pulse as `StubToolKit` doesn't run those)
- Lots of layout occurs, including an attempt to start a 2nd layout pass (which `StubToolKit` won't run)
- The triggering of the 2nd layout pass however would clear the size cache in preparation for a next layout pass
- The stage is hidden, and the 2nd layout pass never runs
- A new Stage is created with the reused ToolBar, and luckily its size cache was cleared so it had to redo the calculations with the new render scale.

In the version with the fix in this PR applied, no 2nd layout pass is triggered, and thus the size cache was not cleared, and the reuse of the ToolBar node would then happily use size values belonging to the old render scale.

I also tested `ToolBar` on my own system (with a real program), and dragged the window from a monitor with 150% to 125% scale, and  the tool bar looked okay.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3438146066

From kcr at openjdk.org  Thu Oct 23 17:11:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 17:11:18 GMT
Subject: RFR: 8370253: CodeArea: NPE on copy
In-Reply-To: 
References: 
Message-ID: <1fA-RKM9eymEtFbg2KAXTe431L79QUsUMy8VphTMQoo=.ad436a42-4058-46f3-ad28-5982f1e50aba@github.com>

On Tue, 21 Oct 2025 15:38:38 GMT, Andy Goryachev  wrote:

> Fixes a missing `null` check in `CodeArea.copy()` when the `syntaxHighlighter` property is set. 
> 
> Also
> - made sure other callers check for null
> - removed dead code

LGTM. The newly added `copyWithSyntaxDecorator` test fails without the fix and passes with the fix.

This is a simple enough fix that a single reviewer is sufficient.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1942#pullrequestreview-3371283615
PR Comment: https://git.openjdk.org/jfx/pull/1942#issuecomment-3438150686

From angorya at openjdk.org  Thu Oct 23 17:20:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 17:20:14 GMT
Subject: RFR: 8369085: RichTextArea SELECT_PARAGRAPH to include line
 separator
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Oct 2025 21:28:48 GMT, Andy Goryachev  wrote:

> RichTextArea.Tag.SELECT_PARAGRAPH or RichTextArea.selectParagraph() must include the trailing line separator (if present).
> 
> This is a behavioral change, but a simple one (an obvious bug) - maybe one reviewer is sufficient.  I don't think this needs a CSR.
> 
> Some interdependency exists between this PR and #1944.  
> Depending which gets integrated first, changes in tests will be needed.

thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1940#issuecomment-3438185027

From angorya at openjdk.org  Thu Oct 23 17:20:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 17:20:15 GMT
Subject: Integrated: 8369085: RichTextArea SELECT_PARAGRAPH to include line
 separator
In-Reply-To: 
References: 
Message-ID: 

On Mon, 20 Oct 2025 21:28:48 GMT, Andy Goryachev  wrote:

> RichTextArea.Tag.SELECT_PARAGRAPH or RichTextArea.selectParagraph() must include the trailing line separator (if present).
> 
> This is a behavioral change, but a simple one (an obvious bug) - maybe one reviewer is sufficient.  I don't think this needs a CSR.
> 
> Some interdependency exists between this PR and #1944.  
> Depending which gets integrated first, changes in tests will be needed.

This pull request has now been integrated.

Changeset: 42fd4eb8
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/42fd4eb827c79b5c273da2598a5435fb7cb4eb6c
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8369085: RichTextArea SELECT_PARAGRAPH to include line separator

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Thu Oct 23 17:24:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 17:24:13 GMT
Subject: RFR: 8370253: CodeArea: NPE on copy
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 15:38:38 GMT, Andy Goryachev  wrote:

> Fixes a missing `null` check in `CodeArea.copy()` when the `syntaxHighlighter` property is set. 
> 
> Also
> - made sure other callers check for null
> - removed dead code

thank you

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

PR Comment: https://git.openjdk.org/jfx/pull/1942#issuecomment-3438194320

From angorya at openjdk.org  Thu Oct 23 17:24:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 17:24:14 GMT
Subject: Integrated: 8370253: CodeArea: NPE on copy
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 15:38:38 GMT, Andy Goryachev  wrote:

> Fixes a missing `null` check in `CodeArea.copy()` when the `syntaxHighlighter` property is set. 
> 
> Also
> - made sure other callers check for null
> - removed dead code

This pull request has now been integrated.

Changeset: a4e4142a
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/a4e4142a2b787cb51e20103d650e568eac8ed3cc
Stats:     91 lines in 3 files changed: 70 ins; 18 del; 3 mod

8370253: CodeArea: NPE on copy

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Thu Oct 23 17:28:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 17:28:31 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v2]
In-Reply-To: 
References: 
Message-ID: 

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.

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

 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - tests
 - line endings

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=01
  Stats: 261 lines in 13 files changed: 232 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

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

From jhendrikx at openjdk.org  Thu Oct 23 17:47:36 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 23 Oct 2025 17:47:36 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 15:52:55 GMT, Kevin Rushforth  wrote:

> Reviewers: @johanvos @kevinrushforth @arapte
> 
> We will need a unit test for this. 

I think I can add one that confirms that no 2nd layout pass occurs when it is not needed when detected changes are part of the current pass.

> What is the risk of regression?

I think it is certainly possible that some poorly constructed `layoutChildren` methods may inadvertently be relying on a 2nd layout pass occurring whenever there is a major UI change (when a control changes sufficiently that its parent must also change size).  If that 2nd pass however did anything more than "confirming" the first layout pass, then this likely would result in an infinite layout loop (whereas now it would stop after a single pass).  Assuming that controls that create infinite layout loops are fixed before they reach a wide audience (as you'd likely notice the drain on resources) it seems to me that it is unlikely such controls are in active use.

Note that it is really easy to get the "old" behavior; just return `false` in `Parent::inLayoutChildren` -- I've been using this to test differences.  If we're really worried this may cause problems, we could turn this into a system property so people may opt out of this fix.

The benefits of this fix could be a reduction in layout passes by half when doing things like resizing windows.  This may be quite noticeable on heavy controls like TableViews.

> Are there additional tests that we could add to help detect any regressions?

Code that may not work correctly with this fix is code where a container is unable to size and position its direct children in a stable fashion in one pass.  If the container is tracking state between layout passes, is not clearing caches at the right time, etc, then a 2nd layout pass (with all else being equal) may result in its direct children being positioned differently.  It's possible some code out there has such problems; they would currently require a 2nd (and perhaps a 3rd or 4th pass) before reaching a stable set of positions and sizes for its direct children.  Note that if they never stabilize, the code before this fix would just keep running layout passes indefinitely.  The fixed code will only do so once regardless.

As soon as anything other than the container and its direct children is modified (ie. a sibling container, a grand child, or a child of a sibling container), then this code won't block another layout pass, so any regressions will be limited to containers being unable to decide how to position its children in a single pass.  If the layout children code modifies some grand child, or some other node it happens to have a reference to, then this will still result in a new layout pass.

I could write a test that will work with the old code, and fail with the new code (simple counting layout passes, or having some state that requires multiple passes would work to "detect" this fix) but am unsure what purpose that would serve.  It's not a supported or documented use of the layout system.  Layouts that need time to settle should still have a strict opinion on the positioning of a single container's direct children, but are likely being jostled by other influences (sibling containers, grand children).  Such situations should still trigger further layout passes until everything converges (hopefully).

Note that "failure" here would just mean that it shows you the result of the first pass; FX would not crash or go into infinite loops.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3438319381

From duke at openjdk.org  Thu Oct 23 19:15:47 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 23 Oct 2025 19:15:47 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

I've found a layout issue when using HeaderBar in Dialogs. This only occurs when:

- you use a HeaderBar
- a preferred width is set on the DialogPane

When using HeaderBar (clipped):
image


When not using HeaderBar:
image


Code to reproduce:

public class DialogBugDemo extends Application {

    @Override
    public void start(Stage stage) {
        Button infoBtn = new Button("Show Two Alerts");
        infoBtn.setOnAction(e -> {
            showInfo(true); // With HeaderBar - content clipping issue
            showInfo(false); // Without HeaderBar - works fine
        });
        stage.setScene(new Scene(new VBox(10, infoBtn), 400, 300));
        stage.show();
    }

    private void showInfo(boolean withHeaderBar) {
        Alert alert = new Alert(AlertType.INFORMATION);
        alert.setHeaderText(null);

        // Set preferred width causing the issue to manifest, no issue without it
        alert.getDialogPane().setPrefWidth(400); // Comment out and bug goes away

        alert.getDialogPane().setContent(createVbox());

        // Display issues only occur when HeaderBar is set
        if (withHeaderBar) {
            alert.setHeaderBar(new HeaderBar());
            alert.initStyle(StageStyle.EXTENDED);
        }

        alert.show();
    }

    private  VBox createVbox() {
        TextFlow tf = new TextFlow(
                new Text("1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0; end of first TextFlow.")
        );

        TextFlow tf2 = new TextFlow(
                new Text("1 2 3 4 5 6 7 8 9 0 1 sdf 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0; end of second TextFlow.")
        );

        return new VBox(tf, new VBox(tf2));
    }

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

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3438695394

From kcr at openjdk.org  Thu Oct 23 19:38:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Oct 2025 19:38:37 GMT
Subject: RFR: 8369836: Update HeaderBar API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 17 Oct 2025 02:22:04 GMT, Michael Strau?  wrote:

>> The `HeaderBar` control currently has three areas: `leading`, `center`, and `trailing`. Additionally, there's `leftSystemInset` and `rightSystemInset`, which are not RTL adjusted. I've come to the understanding that there is no particularly good reason for this, because every time you would want to use this information for layout purposes, it should also be adjusted for RTL.
>> 
>> With this in mind, there are three changes for the `HeaderBar` control:
>> 1. Rename `leading` to `left`, and `trailing` to `right`, which aligns the terminology with `BorderPane`.
>> 2. Adjust `leftSystemInset` and `rightSystemInset` for RTL.
>> 3. Make `leftSystemInset`, `rightSystemInset`, and `minSystemHeight` attached properties for `Stage`.
>> 
>> With this change, the `HeaderBar` control is more semantically consistent and easier to use, and the renamed `left` and `right` areas now show its close relationship with `BorderPane`.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make leftSystemInset/rightSystemInset/minSystemHeight attached properties

The API changes look good. I left a couple inline comments and questions.

Your proposal to add attached Properties seems reasonable and natural. My only question is whether the property name should be prefixes with the fully-qualified class name rather than just the unqualified name.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 287:

> 285:      *
> 286:      * @param stage the {@code Stage}
> 287:      * @return the {@code leftSystemInset} property

Needs `@since 26` javadoc tag (for all new methods).

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 429:

> 427:      * The left area of the {@code HeaderBar}.
> 428:      *
> 429:      * @defaultValue {@code null}

Needs `@since 26` javadoc tag here and all other renamed methods (if the method name or signature changes then it is a new method in 26).

modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 888:

> 886:             this.leftSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.leftSystemInset", EMPTY);
> 887:             this.rightSystemInset = new ReadOnlyObjectWrapper<>(stage, "HeaderBar.rightSystemInset", EMPTY);
> 888:             this.minSystemHeight = new ReadOnlyDoubleWrapper(stage, "HeaderBar.minSystemHeight");

Should the classname prefix in the property `name` be fully qualified? If it were, then a utility could find the corresponding method(s) from the bean using the convention that if a name contains a `.`, it is an attached property with the bean being an argument to the named (static) method.

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

PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3371685356
PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2456487752
PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2456509801
PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2456522184

From duke at openjdk.org  Thu Oct 23 19:53:44 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Thu, 23 Oct 2025 19:53:44 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

More strange behaviour, this time using Labels and setting a min height, leads to different behaviours...

image


public class DialogBugDemoTwo extends Application {

    @Override
    public void start(Stage stage) {
        Button infoBtn = new Button("Show Two Alerts");
        infoBtn.setOnAction(e -> {
            showInfo(true, false, "with header, NO min height");
            showInfo(false, true, "NO header, with min height");
            showInfo(true, true, "with header, with min height");
            showInfo(false, false, "NO header, NO min height");
        });
        stage.setScene(new Scene(new VBox(10, infoBtn), 400, 300));
        stage.show();
    }

    private void showInfo(boolean withHeaderBar, boolean setMinHeight, String desc) {
        Alert alert = new Alert(AlertType.INFORMATION);
        alert.setHeaderText(null);
        alert.initModality(Modality.NONE);

        // Set preferred width causing the issue to manifest, no issue without it
        alert.getDialogPane().setPrefWidth(600); // Comment out and bug goes away

        alert.getDialogPane().setContent(createVbox(desc));

        if (setMinHeight) {
            alert.getDialogPane().setMinHeight(Region.USE_PREF_SIZE);
        }
        // Display issues only occur when HeaderBar is set
        if (withHeaderBar) {
            alert.setHeaderBar(new HeaderBar());
            alert.initStyle(StageStyle.EXTENDED);
        }

        alert.show();
    }

    private VBox createVbox(String desc) {
        final Label lbl1 = new Label(desc + ".... 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0; end of first Label.");
        lbl1.setWrapText(true);

        final Label lbl2 = new Label("1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0; end of second Label.");
        lbl2.setWrapText(true);

        return new VBox(lbl1, new VBox(lbl2));
    }

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

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3438861997

From andy.goryachev at oracle.com  Thu Oct 23 22:09:18 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 23 Oct 2025 22:09:18 +0000
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
 
 
Message-ID: 

> We will need a unit test for this.

Perhaps we could even get it a bit further than that.  What would you say could be a sufficiently comprehensive set of tests/scenarios to reduce the probability of regression?

Let's say, we limit the depth of the hierarchy to 3 (node-parent-parent), then the combinatorial complexity should still be manageable.

What do you think?

-andy

From: openjfx-dev  on behalf of John Hendrikx 
Date: Thursday, October 23, 2025 at 10:47
To: openjfx-dev at openjdk.org 
Subject: Re: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass

On Thu, 23 Oct 2025 15:52:55 GMT, Kevin Rushforth  wrote:

> Reviewers: @johanvos @kevinrushforth @arapte
>
> We will need a unit test for this.

I think I can add one that confirms that no 2nd layout pass occurs when it is not needed when detected changes are part of the current pass.

> What is the risk of regression?

I think it is certainly possible that some poorly constructed `layoutChildren` methods may inadvertently be relying on a 2nd layout pass occurring whenever there is a major UI change (when a control changes sufficiently that its parent must also change size).  If that 2nd pass however did anything more than "confirming" the first layout pass, then this likely would result in an infinite layout loop (whereas now it would stop after a single pass).  Assuming that controls that create infinite layout loops are fixed before they reach a wide audience (as you'd likely notice the drain on resources) it seems to me that it is unlikely such controls are in active use.

Note that it is really easy to get the "old" behavior; just return `false` in `Parent::inLayoutChildren` -- I've been using this to test differences.  If we're really worried this may cause problems, we could turn this into a system property so people may opt out of this fix.

The benefits of this fix could be a reduction in layout passes by half when doing things like resizing windows.  This may be quite noticeable on heavy controls like TableViews.

> Are there additional tests that we could add to help detect any regressions?

Code that may not work correctly with this fix is code where a container is unable to size and position its direct children in a stable fashion in one pass.  If the container is tracking state between layout passes, is not clearing caches at the right time, etc, then a 2nd layout pass (with all else being equal) may result in its direct children being positioned differently.  It's possible some code out there has such problems; they would currently require a 2nd (and perhaps a 3rd or 4th pass) before reaching a stable set of positions and sizes for its direct children.  Note that if they never stabilize, the code before this fix would just keep running layout passes indefinitely.  The fixed code will only do so once regardless.

As soon as anything other than the container and its direct children is modified (ie. a sibling container, a grand child, or a child of a sibling container), then this code won't block another layout pass, so any regressions will be limited to containers being unable to decide how to position its children in a single pass.  If the layout children code modifies some grand child, or some other node it happens to have a reference to, then this will still result in a new layout pass.

I could write a test that will work with the old code, and fail with the new code (simple counting layout passes, or having some state that requires multiple passes would work to "detect" this fix) but am unsure what purpose that would serve.  It's not a supported or documented use of the layout system.  Layouts that need time to settle should still have a strict opinion on the positioning of a single container's direct children, but are likely being jostled by other influences (sibling containers, grand children).  Such situations should still trigger further layout passes until everything converges (hopefully).

Note that "failure" here would just mean that it shows you the result of the first pass; FX would not crash or go into infinite loops.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3438319381
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Thu Oct 23 22:11:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 22:11:04 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v2]
In-Reply-To: 
References: 
Message-ID: 

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

>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>  * map modification that would otherwise be reported as repeated invocations of the listener.
>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>  * reported with subsequent listener invocations.
>  * 

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

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

 - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
 - Factor out IterableSetChange/IterableMapChange implementations

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1885/files
  - new: https://git.openjdk.org/jfx/pull/1885/files/747609b7..6801fdcd

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

  Stats: 608 lines in 7 files changed: 307 ins; 272 del; 29 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  Thu Oct 23 22:40:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 22:40:27 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 22:11:04 GMT, Michael Strau?  wrote:

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

>>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>>  * map modification that would otherwise be reported as repeated invocations of the listener.
>>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>>  * reported with subsequent listener invocations.
>>  * 

>>  * 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 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 op...
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>  - Factor out IterableSetChange/IterableMapChange implementations

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 148:

> 146:                     change.nextAdded(key, newValue);
> 147:                 } else {
> 148:                     V oldValue = backingMap.get(key);

`containsKey()` followed by a `get()` - do you think it's possible to optimize this to avoid looking up twice?  maybe use `get() == null` ?

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 795:

> 793:     }
> 794: 
> 795:     private class SimpleChange extends MapChangeListener.Change {

could this and `BulkChange` classes made static?

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 438:

> 436:             callObservers(new SimpleAddChange(addedElement));
> 437:             return true;
> 438:         }

minor suggestion: 

if (addedElement != null) {
 ..
} else if (addedList != null) {
 ..

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 517:

> 515:         }
> 516: 
> 517:         if (removedList != null) {

same suggestion with `else`

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 532:

> 530:     @Override
> 531:     public void clear() {
> 532:         if (backingSet.size() > 1) {

minor suggestion:

switch(backing.size()) {
case 0:
 break;
case 1:
 ..
default:
 ..
}

though the compiler is probably going to optimize the second call to `size()` out.

modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java line 166:

> 164:                     Thread.currentThread().getUncaughtExceptionHandler().uncaughtException(Thread.currentThread(), e);
> 165:                 }
> 166:             } while (change instanceof IterableSetChange c && c.nextChange());

this is also minor: we are doing instanceof in a loop, perhaps we just need to add a second code path:

if(change instanceof IterableSetChange c) {
 try {...}
} else {
 try {..}

modules/javafx.base/src/main/java/javafx/collections/MapChangeListener.java line 107:

> 105:          * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
> 106:          * map modification that would otherwise be reported as repeated invocations of the listener.
> 107:          * If the listener only fetches some of the pending changes, the rest of the changes will be

suggestion: 
If the listener only fetches some of the pending changes **via the XX() method**
?

modules/javafx.base/src/main/java/javafx/collections/MapChangeListener.java line 110:

> 108:          * reported with subsequent listener invocations.
> 109:          * 

> 110:          * After this method has been called, the current {@code Change} instance is no longer valid and

The language might be a bit confusing (it is to me, at least, where you say it might be the same instance but it is no longer valid?  how is that even possible?).

Perhaps it could be rephrased to something like 'the Change instance returned by this method might be a different and must be used in subsequent operations' or something to that effect.

modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableMapWrapperTest.java line 49:

> 47:     public void partialChangeIterationCausesSubsequentListenerInvocation() {
> 48:         var trace = new ArrayList();
> 49:         var invocations = new int[1];

minor suggestion: an `AtomicInteger` is semantically better than an array

modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableMapWrapperTest.java line 78:

> 76:                 "d added at key k4",
> 77:                 "e added at key k5",
> 78:                 "f added at key k6"),

this is confusing (to me): I don't see the boundary created by the next() call (i.e. between the bulk and individual changes)

or am I missing something?

modules/javafx.base/src/test/java/test/javafx/collections/ObservableMapTest.java line 186:

> 184:     @MethodSource("createParameters")
> 185:     @SuppressWarnings("unchecked")
> 186:     public void testReplaceAll(Callable> mapFactory) throws Exception {

should `ObservableSetTest` be modified as well?

modules/javafx.base/src/test/java/test/javafx/collections/ObservableMapTest.java line 189:

> 187:         setUp(mapFactory);
> 188: 
> 189:         observableMap.replaceAll((key, value) -> switch (key) {

In addition to testing internal details in `ObservableXxxWrapperTests`, shouldn't we also test the bulk change functionality inside this test (i.e. testing the publicly accessible `Set`/`Map` variants)?

I mean, I would rather prioritize testing of the public APIs than some internal implementation.

modules/javafx.base/src/test/java/test/javafx/collections/ObservableMapTest.java line 195:

> 193:         });
> 194: 
> 195:         observer.assertMultipleCalls(call("one", "1", "2"), call("two", "2", "3"));

Also, what I think might still be missing is the tests for all bulk methods (`clear`, `merge`, `putAll`, `replaceAll`) in 3 flavors: 
1. the legacy (no `next()`, individual events)
2. partial, one `next()` call followed by individual events
3. real bulk processing (while last)

same for `Set`s.

modules/javafx.graphics/src/main/java/com/sun/javafx/application/preferences/PlatformPreferences.java line 78:

> 76:     private final PreferenceProperties properties = new PreferenceProperties(this);
> 77: 
> 78:     private MapListenerHelper helper;

I wonder if this change should be undertaken as a separate PR, it's a totally unrelated functionality.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2456912999
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2456973646
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2456997708
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2456999627
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457007252
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457021029
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457052825
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457528078
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457592790
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457601876
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457633691
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457657384
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457688796
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457698289

From angorya at openjdk.org  Thu Oct 23 22:50:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 23 Oct 2025 22:50:20 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 22:11:04 GMT, Michael Strau?  wrote:

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

>>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>>  * map modification that would otherwise be reported as repeated invocations of the listener.
>>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>>  * reported with subsequent listener invocations.
>>  * 

>>  * 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 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 op...
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>  - Factor out IterableSetChange/IterableMapChange implementations

oh, could you please merge the latest master branch?

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3439571688

From mstrauss at openjdk.org  Thu Oct 23 23:31:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 23:31:04 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Oct 2025 19:25:58 GMT, Andy Goryachev  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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/bulk-listeners
>>  - remove unused variable
>>  - Don't repeatedly call backingSet.size()
>>  - Separate code paths for Change/IterableChange
>>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>>  - Factor out IterableSetChange/IterableMapChange implementations
>>  - add tests, documentation
>>  - Implementation of bulk change listeners for ObservableSet and ObservableMap
>
> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 148:
> 
>> 146:                     change.nextAdded(key, newValue);
>> 147:                 } else {
>> 148:                     V oldValue = backingMap.get(key);
> 
> `containsKey()` followed by a `get()` - do you think it's possible to optimize this to avoid looking up twice?  maybe use `get() == null` ?

This is possible if we know that the map doesn't contain null mappings. But since `ObservableMapWrapper` is a wrapper around an arbitray `Map`, we need to account for null mappings. As a consequence of that, we don't know if `map.get(key) == null` means that no mapping is present, or if a mapping is present but its value is `null`.

> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 795:
> 
>> 793:     }
>> 794: 
>> 795:     private class SimpleChange extends MapChangeListener.Change {
> 
> could this and `BulkChange` classes made static?

Yes, I can do that for the existing `Change` implementations, but it's not directly related to bulk change notifications. Maybe another PR would be better.

> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 532:
> 
>> 530:     @Override
>> 531:     public void clear() {
>> 532:         if (backingSet.size() > 1) {
> 
> minor suggestion:
> 
> switch(backing.size()) {
> case 0:
>  break;
> case 1:
>  ..
> default:
>  ..
> }
> 
> though the compiler is probably going to optimize the second call to `size()` out.

I've factored out the repeated call to `backingSet.size()`, and reordered the branches such that == 1 comes before > 1. This reads more cleanly now, and I think is also a bit better than a switch block.

> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java line 166:
> 
>> 164:                     Thread.currentThread().getUncaughtExceptionHandler().uncaughtException(Thread.currentThread(), e);
>> 165:                 }
>> 166:             } while (change instanceof IterableSetChange c && c.nextChange());
> 
> this is also minor: we are doing instanceof in a loop, perhaps we just need to add a second code path:
> 
> if(change instanceof IterableSetChange c) {
>  try {...}
> } else {
>  try {..}

Yes, changed this here and also in `MapListenerHelper`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457888231
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457888283
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457895737
PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457897995

From mstrauss at openjdk.org  Thu Oct 23 23:31:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 23:31:01 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
Message-ID: 

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

>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>  * map modification that would otherwise be reported as repeated invocations of the listener.
>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>  * reported with subsequent listener invocations.
>  * 

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

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

 - Merge branch 'master' into feature/bulk-listeners
 - remove unused variable
 - Don't repeatedly call backingSet.size()
 - Separate code paths for Change/IterableChange
 - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
 - Factor out IterableSetChange/IterableMapChange implementations
 - add tests, documentation
 - Implementation of bulk change listeners for ObservableSet and ObservableMap

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1885/files
  - new: https://git.openjdk.org/jfx/pull/1885/files/6801fdcd..6101be4b

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

  Stats: 150826 lines in 1147 files changed: 81967 ins; 26941 del; 41918 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 mstrauss at openjdk.org  Thu Oct 23 23:35:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 23 Oct 2025 23:35:19 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <4T_NqzfBj5CcGjc9wzXK90BFW-kpMPWDIrJ2HNolLfQ=.570afca2-7e6a-4b5a-8355-6277a4db6e29@github.com>

On Thu, 23 Oct 2025 19:57:10 GMT, Andy Goryachev  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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/bulk-listeners
>>  - remove unused variable
>>  - Don't repeatedly call backingSet.size()
>>  - Separate code paths for Change/IterableChange
>>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>>  - Factor out IterableSetChange/IterableMapChange implementations
>>  - add tests, documentation
>>  - Implementation of bulk change listeners for ObservableSet and ObservableMap
>
> modules/javafx.base/src/main/java/javafx/collections/MapChangeListener.java line 107:
> 
>> 105:          * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>> 106:          * map modification that would otherwise be reported as repeated invocations of the listener.
>> 107:          * If the listener only fetches some of the pending changes, the rest of the changes will be
> 
> suggestion: 
> If the listener only fetches some of the pending changes **via the XX() method**
> ?

Hmm... there's no other method to call in order to fetch more changes. I could add "If the listener only fetches some of the pending changes **with the next() method**". But then again, just in the sentence before we explained that fetching more changes is done by "repeatedly calling this method" (i.e. the `next()` method).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2457916284

From mstrauss at openjdk.org  Fri Oct 24 00:04:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 24 Oct 2025 00:04:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <3-WQ4NBUJggdbcHXvwU1fw8zcYU6h8jkD4WknChpBUo=.aa596afe-127f-480e-9aeb-80d785157465@github.com>

On Thu, 23 Oct 2025 22:16:09 GMT, Andy Goryachev  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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/bulk-listeners
>>  - remove unused variable
>>  - Don't repeatedly call backingSet.size()
>>  - Separate code paths for Change/IterableChange
>>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>>  - Factor out IterableSetChange/IterableMapChange implementations
>>  - add tests, documentation
>>  - Implementation of bulk change listeners for ObservableSet and ObservableMap
>
> modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableMapWrapperTest.java line 78:
> 
>> 76:                 "d added at key k4",
>> 77:                 "e added at key k5",
>> 78:                 "f added at key k6"),
> 
> this is confusing (to me): I don't see the boundary created by the next() call (i.e. between the bulk and individual changes)
> 
> or am I missing something?

This test demonstrates that the sequence of changes is the same, no matter the number of change listener invocations. For this purpose, we assert that the number of changes is as expected (6), but the number of invocations is only 3. In this sense, not seeing a boundary between the invocations is the point.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2458030203

From mstrauss at openjdk.org  Fri Oct 24 00:14:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 24 Oct 2025 00:14:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 23 Oct 2025 21:51:05 GMT, Andy Goryachev  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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into feature/bulk-listeners
>>  - remove unused variable
>>  - Don't repeatedly call backingSet.size()
>>  - Separate code paths for Change/IterableChange
>>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>>  - Factor out IterableSetChange/IterableMapChange implementations
>>  - add tests, documentation
>>  - Implementation of bulk change listeners for ObservableSet and ObservableMap
>
> modules/javafx.base/src/main/java/javafx/collections/MapChangeListener.java line 110:
> 
>> 108:          * reported with subsequent listener invocations.
>> 109:          * 

>> 110:          * After this method has been called, the current {@code Change} instance is no longer valid and
> 
> The language might be a bit confusing (it is to me, at least, where you say it might be the same instance but it is no longer valid?  how is that even possible?).
> 
> Perhaps it could be rephrased to something like 'the Change instance returned by this method might be a different and must be used in subsequent operations' or something to that effect.

Yes, I see that this can be confusing. What I want to bring across is that:
1. You are not allowed to retain a reference to the "last" change instance and expect it to give you correct information after `next()` has been called.
2. You are not allowed to assume, just because the next change instance is the same object as the previous instance, that we're dealing with the same change.

How about this version:

 * 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 logical change. Callers must also not retain a reference
 * to a previous {@code Change} instance and expect it to be valid after this method has been
 * called. Calling any method on an earlier change may result in undefined behavior.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2458069192

From mstrauss at openjdk.org  Fri Oct 24 00:32:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 24 Oct 2025 00:32:21 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
Message-ID: <9nqgiZggrduajVuv_a4L2X5tCDfkwUB6N9W1slTkp-w=.06fb059a-7312-4739-a56f-09f15cf2ac97@github.com>

On Thu, 23 Oct 2025 23:31:01 GMT, Michael Strau?  wrote:

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

>>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>>  * map modification that would otherwise be reported as repeated invocations of the listener.
>>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>>  * reported with subsequent listener invocations.
>>  * 

>>  * 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 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 op...
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/bulk-listeners
>  - remove unused variable
>  - Don't repeatedly call backingSet.size()
>  - Separate code paths for Change/IterableChange
>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>  - Factor out IterableSetChange/IterableMapChange implementations
>  - add tests, documentation
>  - Implementation of bulk change listeners for ObservableSet and ObservableMap

There's one behavioral change with this enhancement that I want to point out.

Previously, bulk operations were just repeated invocations of their single-element counterpart, i.e. `ObservableSetWrapper.addAll(Collection)` would just repeatedly call `ObservableSetWrapper.add(E)` and thereby trigger repeated listener invocations.

Now consider this method:


public interface SetChangeListener {

    abstract class Change {
        /**
         * An observable set that is associated with the change.
         * @return the source set
         */
        public ObservableSet getSet() { ... }
    }
}


Previously, if a listener were to query the source set, it would always correspond to the _current_ state of the set.
With the bulk change enhancement, the source set corresponds to the _final_ state of the set (because all changes have already been applied in bulk).

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3440077428

From duke at openjdk.org  Fri Oct 24 01:45:22 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Fri, 24 Oct 2025 01:45:22 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
Message-ID: 

On Tue, 21 Oct 2025 23:54:55 GMT, Michael Strau?  wrote:

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

Hi. Another bug, a slightly more serious one this time.

Dialogs cannot be re-used. E.g., sequentially calling showAndWait() twice on the same instance, does not work:

![bug](https://github.com/user-attachments/assets/3c3c1614-f0ea-4469-9610-455d4b5e352a)

This works fine on older JFXs:

![nobug](https://github.com/user-attachments/assets/14275cfd-7e81-4332-941a-c264a3a21ab3)

Steps to reproduce:


public class DialogBugDemoThree extends Application {

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

    @Override
    public void start(Stage primaryStage) {
        final Dialog dialog = new Dialog<>();
        dialog.getDialogPane().setContent(new Label("Label"));
        ButtonType okButton = new ButtonType("OK", ButtonBar.ButtonData.OK_DONE);
        dialog.getDialogPane().getButtonTypes().addAll(okButton, ButtonType.CANCEL);

        // Show once
        dialog.showAndWait();

        // Show twice
        // This will NOT work (it shows a tiny window frame with no content)
        dialog.showAndWait();
    }
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3440326580

From mariushanl at web.de  Fri Oct 24 04:58:00 2025
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 24 Oct 2025 04:58:00 +0000
Subject: Allowing a cell to commit the value on focus loss
In-Reply-To: 
References: 
 <9d75e27b-b02a-4e75-86db-de789a51c9ed@gmail.com>
 
 
 <31452e47-f78e-44be-9255-d25b7eee2890@gmail.com>
 
 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Fri Oct 24 04:59:22 2025
From: duke at openjdk.org (Fouad Almalki)
Date: Fri, 24 Oct 2025 04:59:22 GMT
Subject: RFR: 8221261: Deadlock on macOS in JFXPanel app when handling IME
 calls
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 10 Jan 2024 17:39:13 GMT, Kevin Rushforth  wrote:

>> As described in the JBS bug, there is a long-standing deadlock that happens on macOS between the AWT EDT and the JavaFX Application thread (which on macOS is the AppKit thread) when processing Input Method Events (IME) in a WebView node in a JFXPanel.
>> 
>> This PR fixes the deadlock by adding `"AWTRunLoopMode"` to the list of modes that will accept the calls to `performSelectorOnMainThread` used by `_submitForLaterInvocation` and `_invokeAndWait`. These two native methods are the macOS implemention `runLater` and `runAndWait`, respectively, and are used to run Java Runnables on the JavaFX Application Thread.
>> 
>> This deadlock is happening much more often on recent macOS versions, and in macOS 14, pressing CAPS LOCK is sufficient to trigger IME calls.
>> 
>> The OS calls the AWT IME methods on the AppKit thread, which is also the JavaFX Application Thread. The AWT IME callback methods, for example `characterIndexForPoint`, call invokeAndWait to run the IME handler on the AWT Event thread. In the case of JFXPanel, the registered IME handler is in JavaFX code and we often need to run something on the JavaFX Application Thread to avoid threading problems or crashes. See [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) and [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703).
>> 
>> A similar deadlock was observed while trying to fix a threading problem in JFXPanel's handling of  the IME calls as described in [JDK-8322784](https://bugs.openjdk.org/browse/JDK-8322784), so it isn't necessarily limited to using WebView.
>> 
>> Anton Tarasov @forantar proposed a fix (in a comment in the JBS bug) in AWT that would change the invokeAndWait calls used by the IME methods in CInputMethod to call `doAWTRunLoop` with the `processEvents` flag set to true, which will allow all events to be processed while in `doAWTRunLoop`.
>> 
>> NOTE: I had created Draft PR openjdk/jdk#17290 with Anton's proposed fix, expanded to cover all of the cases, but during the discussion it was pointed out that `doAWTRunLoop` should already be able to run selectors via `performSelectorOnMainThread` -- see [this comment](https://github.com/openjdk/jdk/pull/17290#issuecomment-1880001813). The reason `doAWTRunLoop` doesn't process our messages is that it runs the loop in a mode that only handles messages that include a custom `"AWTRunLoopMode"` mode.    
>>           
>> Adding `"AWTRunLoopMode"` to the `performSelectorOnMainThread` calls used by `_submitForLaterInvocation` and `_invokeAndWa...
>
> NOTE to reviewers: If you want to test this with WebView in a JFXPanel, you will also need the fix for [JDK-8322703](https://bugs.openjdk.org/browse/JDK-8322703), which is under review in PR #1321 to avoid a crash (that crash was effectively hidden by this deadlock so it was missed earlier).
> 
> I have created a test branch that has both fixes:
> 
> https://github.com/kevinrushforth/jfx/tree/test-8221261-8322703
> 
> You can either fetch that branch or fetch both PR branches and build. It is not necessary to build the native WebKit if you have an up-to-date library in your cache.

Hi @kevinrushforth, we are trying to run JavaFX on GraalVM native-image on MacOS. When we start the app, `com.sun.glass.ui.mac.MacApplication#runLoop` gets stuck on the native side. We tried everything and couldn't figure out how to solve it. We would really appreciate you help to find the real cause and fix this issue. Thanks.

https://github.com/quarkiverse/quarkus-fx/issues/205

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

PR Comment: https://git.openjdk.org/jfx/pull/1327#issuecomment-3441065342

From jhendrikx at openjdk.org  Fri Oct 24 05:38:19 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 24 Oct 2025 05:38:19 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
> 
> > We will need a unit test for this.
> 
> Perhaps we could even get it a bit further than that. What would you say could be a sufficiently comprehensive set of tests/scenarios to reduce the probability of regression?
> 
> Let's say, we limit the depth of the hierarchy to 3 (node-parent-parent), then the combinatorial complexity should still be manageable.
> 
> What do you think?

As much as I'd like to help out more, after analyzing this problem already for almost two full days, I don't have time to write a comprehensive test suite for one of the more complex systems in JavaFX.  I can of course extend existing tests to get behavioral coverage on this new fix.

So, I think we then should choose what we want.  We can revert https://bugs.openjdk.org/browse/JDK-8360940 and go back to a situation where the layout system can easily get into a bad state while using documented API's, or we can take a critical look at this new fix, which is fixing a long standing problem that was hidden by the bug that was fixed, and could be a major performance improvement for complex UI's.

I think manual testing with some large UI's and/or Monkey Tester should be more than sufficient to discover if this is likely to cause regressions, and I've already been doing so before I submitted this fix (I tend to just apply these fixes to my own code directly, to see how they work out).  

If we're still unsure, a system property can turn this on/off easily, at the cost of getting some redundant layout passes in the "off" mode (as it was before).

I already knew that the detection that `Node` was doing for triggering a 2nd layout pass was bogus, because `isCurrentLayoutChild` is simply not updated at the correct moments for this to work.  It works if you ask if a Node's **parent** is the current layout child of the **grand parent**, but it does not work for one level deeper: asking if a node is the current layout child of its parent.

That the logic looked correct at first glance may have have convinced the original authors that it does work, but it doesn't.  More importantly, it can't be fixed as a fix would require **each** modification of layout X/Y to wrap this change by setting the current layout child first -- that would require updating all layout containers, all 3rd party layout containers, and all 3rd party code that calls `relocate` or sets layout X/Y directly -- an impossibility IMHO.  That's also the reason I didn't fix that immediately, as at the time I didn't see a workable solution.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3441126783

From johan.vos at gluonhq.com  Fri Oct 24 10:59:52 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 24 Oct 2025 12:59:52 +0200
Subject: performance impact of JDK-8360940 in case of a wrong but common
 pattern
In-Reply-To: <58f92e2d-f9ec-4643-b46a-c49ff6843730@oracle.com>
References: 
 
 
 <58f92e2d-f9ec-4643-b46a-c49ff6843730@oracle.com>
Message-ID: 

On Thu, Oct 23, 2025 at 6:00?PM Kevin Rushforth 
wrote:

> Regarding the specification, are you primarily thinking about the need to
> document the implementation of layout or do you think additional
> documentation for the public / protected layout methods (e.g.,
> layoutChildren) or class docs would be useful?
>

I believe the highest priority should go to documentation for openjfx
developers and reviewers. I agree that it would be good to have
docs/guidelines for JavaFX developers, but I think the primary concern is a
deeper knowledge and consistency for our internal development. Most of the
(implicit) specification is in code and different levels of documentation
inside the java files.


> Regarding testing, I can see the need for additional tests. In most cases,
> layout tests can be done using unit tests in the javafx.graphics module.
> These tests use the StubToolkit (instead of the actual QuantumToolkit), so
> glass and prism are not even loaded.
>
> Unrelated to layout or any particular test, switching the javafx.graphics
> and javafx.controls test from StubToolkit to QuantumToolkit + headless
> glass would be an interesting thing to look at. This might a a good
> discussion to split into its own thread. I can definitely see some value in
> doing this.
>

Absolutely.

- Johan


>
> -- Kevin
>
> On 10/23/2025 12:16 AM, Johan Vos wrote:
>
> Hi Johan,
>
> I didn't look in detail yet (and checked with the code), but your analysis
> makes sense. I believe the root problem, though, is lack of
> documentation/specs. Our knowledge is mainly based on reverse engineering
> and reading the code. That allowed me to isolate and describe the "problem"
> I described in my original post, but even that is far from complete, as the
> layout process spans more classes and phases. I typically use pen and paper
> to draw the flow for isolating issues like this, but those pictures are
> never complete.
> The second thing is, testing. Ideally, that should be related to specs,
> but in absence of specs we can test the current situation, and mark that as
> the lower bar. However, that implies that tons of tests would need to be
> added. And even then, there might be fixes that in general would lead to
> less pulses, but in corner cases might have a slight performance penalty.
>
> In summary, I believe the specification part is the most important one.
> That will enable rigorous testing. With the headless platform in place now,
> those tests do not even require a real graphics pipeline.
>
> - Johan
>
> On Thu, Oct 23, 2025 at 2:49?AM John Hendrikx 
> wrote:
>
>> Johan, I had a closer look.
>>
>> TLDR:
>>
>> - FX currently almost always does two layout passes, with the 2nd pass
>> not changing anything, due to a flaw in Node's relayout trigger logic
>> - I think it may be possible to fix this, and as a side effect also fixes
>> your infinite layout loop scenario
>>
>> Longer version:
>>
>> Although I think the original fix is correct (as it fixes broken state
>> tracking), I do see that the fix may cause existing flaws, that were swept
>> under the rug before, to become more problematic.
>>
>> I think the fundamental reason for the relayout trigger code in Node on
>> LayoutX/Y changes is to catch cases when these are modified OUTSIDE the
>> scope of its direct Parent's layoutChildren call. In fact, it seemingly
>> does its best to detect when a change occurs as part of a Parent's
>> layoutChildren call as seen in this code and the clarifying comment:
>>
>> // Propagate layout if this change isn't triggered by its parent
>>
>> if (p != null && !p.isCurrentLayoutChild(Node.this)) {
>>
>> However, this check utterly fails in almost all situations, for the
>> simple reason that the child node which has its layout X/Y changed is NOT
>> considered the current layout child by its parent.  None of the containers
>> will update the current layout child before doing each layoutX/Y change (as
>> that would be very cumbersome...)  However, we're not actually interested
>> in that.  All we want to know is:
>>
>>      *** Is this layout X/Y change performed while the direct
>> Parent's layoutChildren() call is higher up in the call stack? ***
>>
>> There are two ways to answer that question:
>>
>> - One can ask the *grandparent* if the child's parent is the current
>> layout child -> the answer would be yes, BUT it only means its layout() is
>> running, and often also its layoutChildren() (so this isn't perfect)
>> - Another option is to ask the direct parent if it is currently
>> performing layout -> the answer would be yes, and it normally means its
>> layoutChildren is running, but the flag isn't cleared immediately after the
>> call completes, so this is also a bit flawed; excerpt from Parent::layout():
>>
>> performingLayout = true;
>>
>> layoutChildren(); ... (more code that triggers layouts for the rest of
>> the sub tree) ...
>>
>> performingLayout = false;
>>
>> The flag however is incredibly close to what we need, and an extra
>> tighter flag that is reset immediately after `layoutChildren` completes
>> (instead of after the whole subtree completes layout) would be exactly what
>> we need.
>>
>> So now if Node wants to know if a layout X/Y is changed because the
>> parent's layout children triggered it, then all it needs to ask the parent
>> node is if this new flag is set.
>>
>> With this fix, your scenario would also no longer trigger a layout loop,
>> assuming the node you are modifying is a direct child of the node on which
>> layoutChildren is overridden.
>> The only reason that currently this broken logic is not already
>> triggering infinite layouts is that a 2nd pass will set all values to the
>> same values, and Node will not trigger its logic if the value was
>> unchanged.  However, its already broken that a 2nd pass is necessary at
>> all.  In effect, JavaFX is currently almost always doing **two** layout
>> passes; one that changes all the positions and sizes, and another that
>> "confirms" these unnecessarily.
>>
>> As it is always dangerous to play with the layout logic, this will need
>> to be well tested, but I think we really need to fix this, or revert the
>> JDK-8360940 change as I think it may otherwise cause too much problems,
>> even though it is fixing problems and just exposing new ones...
>>
>> --John
>>
>>
>>
>> On 21/10/2025 21:42, Johan Vos wrote:
>>
>> I recently noticed a performance degradation in a JavaFX application,
>> that I could trace to the fix for JDK-8360940 [1]. I believe the fix is
>> correct, but it can cause infinite pulses in some cases. It is somehow
>> discussed in the second of the 2 errors in Parent, in [2], but I believe
>> this pattern is used often, and will now lead to infinite pulses
>>
>> For example, a class extending Parent and implementing layoutChildren
>> that does something like this:
>>
>> @Override
>> protected void layoutChildren() {
>>     super.layoutChildren();
>>     if (someSpecificCondition) {
>>         someManagedNode.relocate(someX, someY);
>>     }
>> }
>>
>> Support the someManagedNode is at (x0, y) before the pulse runs.
>> The call to super.layoutChildren() will set the layoutX/Y to e.g. superX,
>> superY and it will request a new pulse (in case superX != x0 or superY !=
>> y).
>> Next, the someManagedNode is conditionally repositioned to someX, someY .
>> In the next pulse (immediately following this pulse), the
>> super.layoutChildren will again set the layoutX/Y to superX, superY, and
>> trigger a new pulse, no matter what happens afterwards. The conditional
>> code will again reset the layoutX/Y to someX, someY (which is what they had
>> before this pulse started layoutChildren()), but the next pulse is
>> scheduled AND it will visit this Node.
>>
>> Even though in the end the layoutX/layoutY properties of someManagedNode
>> are not changed as the result of layoutChildren, a new pulse will be
>> requested because there was an intermediate value (which never got
>> rendered, as it was changed again even before the layoutChildren returns)
>> that triggered the requestNextPulse.
>>
>> I think this pattern is used in a number of external controls. It worked
>> "by accident" until the issue in JDK-8360940 was fixed. In defense of the
>> pattern above, one could argue that a requestPulse should only be triggered
>> if the triggering property was altered at the end of the layoutPhase (that
>> is, if there is a difference in value between the start and the end of the
>> layoutPhase).
>>
>> In summary, I don't propose to change anything, and I agree with the
>> commit in [1], but it might need some attention in the release notes or
>> docs.
>>
>> - Johan
>>
>>
>> [1]
>> https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
>> [2] https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lkostyra at openjdk.org  Fri Oct 24 13:40:35 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 24 Oct 2025 13:40:35 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

Looks good. I tested this on Windows with rich editor demo and using both polish and spanish IME shortcuts - all work fine after this change

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1938#pullrequestreview-3376799883

From lkostyra at openjdk.org  Fri Oct 24 13:40:36 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 24 Oct 2025 13:40:36 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
 
Message-ID: <31HmBtdNOiDujQeJ4DVl_XMcWJpUMUUhJJU0TsGht7c=.eefb979c-a043-4272-b0e5-64d6f65980b4@github.com>

On Fri, 24 Oct 2025 13:36:45 GMT, Lukasz Kostyra  wrote:

> I tested this on Windows 

I wrote this comment on Windows and something shorted in my brain when I was typing this. I meant on Linux, Ubuntu 24.04.2 :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3443208832

From angorya at openjdk.org  Fri Oct 24 14:18:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 14:18:11 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

I am curious: could you tell me more about Polish/Spanish IME, what exactly have you try?
The reason I ask is (and I don't have much experience with European keyboards) is that these might go through the standard pathway, a regular keystroke.

The IME on the other hand, is a special UI that pops up with a list of candidates, and it's usually used in CJK languages.

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3443404193

From kcr at openjdk.org  Fri Oct 24 14:40:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Oct 2025 14:40:05 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 24 Oct 2025 05:33:45 GMT, John Hendrikx  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ToolBarSkinTest
>>   
>>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.
>
>> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
>> 
>> > We will need a unit test for this.
>> 
>> Perhaps we could even get it a bit further than that. What would you say could be a sufficiently comprehensive set of tests/scenarios to reduce the probability of regression?
>> 
>> Let's say, we limit the depth of the hierarchy to 3 (node-parent-parent), then the combinatorial complexity should still be manageable.
>> 
>> What do you think?
> 
> As much as I'd like to help out more, after analyzing this problem already for almost two full days, I don't have time to write a comprehensive test suite for one of the more complex systems in JavaFX.  I can of course extend existing tests to get behavioral coverage on this new fix.
> 
> So, I think we then should choose what we want.  We can revert https://bugs.openjdk.org/browse/JDK-8360940 and go back to a situation where the layout system can easily get into a bad state while using documented API's, or we can take a critical look at this new fix, which is fixing a long standing problem that was hidden by the bug that was fixed, and could be a major performance improvement for complex UI's.
> 
> I think manual testing with some large UI's and/or Monkey Tester should be more than sufficient to discover if this is likely to cause regressions, and I've already been doing so before I submitted this fix (I tend to just apply these fixes to my own code directly, to see how they work out).  
> 
> If we're still unsure, a system property can turn this on/off easily, at the cost of getting some redundant layout passes in the "off" mode (as it was before).
> 
> I already knew that the detection that `Node` was doing for triggering a 2nd layout pass was bogus, because `isCurrentLayoutChild` is simply not updated at the correct moments for this to work.  It works if you ask if a Node's **parent** is the current layout child of the **grand parent**, but it does not work for one level deeper: asking if a node is the current layout child of its parent.
> 
> That the logic looked correct at first glance may have have convinced the original authors that it does work, but it doesn't.  More importantly, it can't be fixed as a fix would require **each** modification of layout X/Y to wrap this change by setting the current layout child first -- that would require updating all layout containers, all 3rd party layout containers, and all 3rd party code that calls `relocate` or sets...

@hjohn Thank you for providing the additional analysis. This will help those of us who will review this proposed fix evaluate it to see if we can poke any holes in it.

As you say, we have two choices before us: fix this bug or revert the fix for [JDK-8360940](https://bugs.openjdk.org/browse/JDK-8360940). If we can convince ourselves that this is the right fix, taking this fix would be preferable to re-introducing JDK-8360940.

As for testing, I think manual testing using various apps (e.g., Ensemble, MonkeyTester, SceneBuilder) is needed. And while we also need a new test for _this_ fix -- that is, a test that fails before and passes after the fix -- I would agree that adding a whole battery of functional tests for layout is out of scope and better done as a follow-on.

Finally, as you point out, we could provide a system property to go back to the way we did it before. If we do that (which I am not advocating at this point in the review), we might consider having that flag also revert the behavior of [JDK-8360940](https://bugs.openjdk.org/browse/JDK-8360940).

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3443507993

From andy.goryachev at oracle.com  Fri Oct 24 15:09:28 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 24 Oct 2025 15:09:28 +0000
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Right.  Apart from a unit test for this specific issue, I would like us at least to think? about enumerating the typical scenarios and scenarios where the outcome might be different.

-andy

From: openjfx-dev  on behalf of Kevin Rushforth 
Date: Friday, October 24, 2025 at 07:40
To: openjfx-dev at openjdk.org 
Subject: Re: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v2]

On Fri, 24 Oct 2025 05:33:45 GMT, John Hendrikx  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   Fix ToolBarSkinTest
>>
>>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.
>
>> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
>>
>> > We will need a unit test for this.
>>
>> Perhaps we could even get it a bit further than that. What would you say could be a sufficiently comprehensive set of tests/scenarios to reduce the probability of regression?
>>
>> Let's say, we limit the depth of the hierarchy to 3 (node-parent-parent), then the combinatorial complexity should still be manageable.
>>
>> What do you think?
>
> As much as I'd like to help out more, after analyzing this problem already for almost two full days, I don't have time to write a comprehensive test suite for one of the more complex systems in JavaFX.  I can of course extend existing tests to get behavioral coverage on this new fix.
>
> So, I think we then should choose what we want.  We can revert https://bugs.openjdk.org/browse/JDK-8360940 and go back to a situation where the layout system can easily get into a bad state while using documented API's, or we can take a critical look at this new fix, which is fixing a long standing problem that was hidden by the bug that was fixed, and could be a major performance improvement for complex UI's.
>
> I think manual testing with some large UI's and/or Monkey Tester should be more than sufficient to discover if this is likely to cause regressions, and I've already been doing so before I submitted this fix (I tend to just apply these fixes to my own code directly, to see how they work out).
>
> If we're still unsure, a system property can turn this on/off easily, at the cost of getting some redundant layout passes in the "off" mode (as it was before).
>
> I already knew that the detection that `Node` was doing for triggering a 2nd layout pass was bogus, because `isCurrentLayoutChild` is simply not updated at the correct moments for this to work.  It works if you ask if a Node's **parent** is the current layout child of the **grand parent**, but it does not work for one level deeper: asking if a node is the current layout child of its parent.
>
> That the logic looked correct at first glance may have have convinced the original authors that it does work, but it doesn't.  More importantly, it can't be fixed as a fix would require **each** modification of layout X/Y to wrap this change by setting the current layout child first -- that would require updating all layout containers, all 3rd party layout containers, and all 3rd party code that calls `relocate` or sets...

@hjohn Thank you for providing the additional analysis. This will help those of us who will review this proposed fix evaluate it to see if we can poke any holes in it.

As you say, we have two choices before us: fix this bug or revert the fix for [JDK-8360940](https://bugs.openjdk.org/browse/JDK-8360940). If we can convince ourselves that this is the right fix, taking this fix would be preferable to re-introducing JDK-8360940.

As for testing, I think manual testing using various apps (e.g., Ensemble, MonkeyTester, SceneBuilder) is needed. And while we also need a new test for _this_ fix -- that is, a test that fails before and passes after the fix -- I would agree that adding a whole battery of functional tests for layout is out of scope and better done as a follow-on.

Finally, as you point out, we could provide a system property to go back to the way we did it before. If we do that (which I am not advocating at this point in the review), we might consider having that flag also revert the behavior of [JDK-8360940](https://bugs.openjdk.org/browse/JDK-8360940).

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3443507993
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mfox at openjdk.org  Fri Oct 24 15:17:45 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 24 Oct 2025 15:17:45 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

On Mac and Linux dead key sequences are delivered as InputMethodEvents. When typing ? using dead keys the user previews the diacritic mark (?) as composed text and then the final character (?) is delivered as committed text.

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3443679439

From angorya at openjdk.org  Fri Oct 24 15:21:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 15:21:19 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: <4Sce2YSY5YsErPhuw_lemBSSfWDW7BRIaPTl87jKRAQ=.45b5c1d0-30e3-43e7-85e7-c94eb9892064@github.com>

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

Does it show any underline/dotted shapes?  How do you type ? in German layout (on macOS)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3443691789

From mfox at openjdk.org  Fri Oct 24 15:44:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 24 Oct 2025 15:44:23 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

I usually test using a US keyboard and typing Option+e for ? or Option+u for ? or Option+n for ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3443775931

From angorya at openjdk.org  Fri Oct 24 16:23:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 16:23:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 23 Oct 2025 23:24:54 GMT, Michael Strau?  wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 795:
>> 
>>> 793:     }
>>> 794: 
>>> 795:     private class SimpleChange extends MapChangeListener.Change {
>> 
>> could this and `BulkChange` classes made static?
>
> Yes, I can do that for the existing `Change` implementations, but it's not directly related to bulk change notifications. Maybe another PR would be better.

since you are already here...  saves a pointer maybe

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461190925

From kcr at openjdk.org  Fri Oct 24 17:26:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Oct 2025 17:26:29 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 24 Oct 2025 16:20:29 GMT, Andy Goryachev  wrote:

>> Yes, I can do that for the existing `Change` implementations, but it's not directly related to bulk change notifications. Maybe another PR would be better.
>
> since you are already here...  saves a pointer maybe

"since you are already here" is not usually sufficient justification for fixing an unrelated bug. So it probably makes sense to do for any new class added, but I'd leave the existing ones alone.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461365504

From angorya at openjdk.org  Fri Oct 24 18:04:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:04:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Fri, 24 Oct 2025 17:23:21 GMT, Kevin Rushforth  wrote:

>> since you are already here...  saves a pointer maybe
>
> "since you are already here" is not usually sufficient justification for fixing an unrelated bug. So it probably makes sense to do for any new class added, but I'd leave the existing ones alone.

I thought it **is** a new class.  But sure, I am ok to keep the code as is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461459163

From angorya at openjdk.org  Fri Oct 24 18:09:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:09:26 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4WIjCTmG9GfT6beSBY49D2ox9FBo38v_UJmWO1Psav4=.7c1e41e6-ff3d-49fe-92f7-c7c84918c49e@github.com>

On Fri, 24 Oct 2025 00:12:01 GMT, Michael Strau?  wrote:

>> modules/javafx.base/src/main/java/javafx/collections/MapChangeListener.java line 110:
>> 
>>> 108:          * reported with subsequent listener invocations.
>>> 109:          * 

>>> 110:          * After this method has been called, the current {@code Change} instance is no longer valid and
>> 
>> The language might be a bit confusing (it is to me, at least, where you say it might be the same instance but it is no longer valid?  how is that even possible?).
>> 
>> Perhaps it could be rephrased to something like 'the Change instance returned by this method might be a different and must be used in subsequent operations' or something to that effect.
>
> Yes, I see that this can be confusing. What I want to bring across is that:
> 1. You are not allowed to retain a reference to the "last" change instance and expect it to give you correct information after `next()` has been called.
> 2. You are not allowed to assume, just because the next change instance is the same object as the previous instance, that we're dealing with the same change.
> 
> How about this version:
> 
>  * 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 logical change. Callers must also not retain a reference
>  * to a previous {@code Change} instance and expect it to be valid after this method has been
>  * called. Calling any method on an earlier change may result in undefined behavior.

this is still a bit confusing... "identity" where did that come from?

maybe just tell them what they need to do instead: discard the last instance and use the one returned by `next()` instead?  what do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461481444

From angorya at openjdk.org  Fri Oct 24 18:16:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:16:19 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: <9nqgiZggrduajVuv_a4L2X5tCDfkwUB6N9W1slTkp-w=.06fb059a-7312-4739-a56f-09f15cf2ac97@github.com>
References: 
 
 <9nqgiZggrduajVuv_a4L2X5tCDfkwUB6N9W1slTkp-w=.06fb059a-7312-4739-a56f-09f15cf2ac97@github.com>
Message-ID: 

On Fri, 24 Oct 2025 00:30:10 GMT, Michael Strau?  wrote:

> There's one behavioral change with this enhancement that I want to point out.
we probably need to add this explanation to `SetChangeListener.Change.getSet()` javadoc.  I assume the same goes for `MapChangeListener.Change.getMap()` ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3444335456

From angorya at openjdk.org  Fri Oct 24 18:16:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:16:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: <3-WQ4NBUJggdbcHXvwU1fw8zcYU6h8jkD4WknChpBUo=.aa596afe-127f-480e-9aeb-80d785157465@github.com>
References: 
 
 
 <3-WQ4NBUJggdbcHXvwU1fw8zcYU6h8jkD4WknChpBUo=.aa596afe-127f-480e-9aeb-80d785157465@github.com>
Message-ID: 

On Fri, 24 Oct 2025 00:01:30 GMT, Michael Strau?  wrote:

>> modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ObservableMapWrapperTest.java line 78:
>> 
>>> 76:                 "d added at key k4",
>>> 77:                 "e added at key k5",
>>> 78:                 "f added at key k6"),
>> 
>> this is confusing (to me): I don't see the boundary created by the next() call (i.e. between the bulk and individual changes)
>> 
>> or am I missing something?
>
> This test demonstrates that the sequence of changes is the same, no matter the number of change listener invocations. For this purpose, we assert that the number of changes is as expected (6), but the number of invocations is only 3. In this sense, not seeing a boundary between the invocations is the point.

Ok, so if I were to write a test per the public API, two things should be tested: the changes and the bulk aspect.  So perhaps the toString() or the test's toString() can be modified to explicitly encode the bulk aspect.  In other words, the test might look like this:

expect([k3=c, k4=d],[k5=e],[k6=f])

if the test calls next on k3 and k4, then individual events come for k5, k6.
This way you test both API functions in one test.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461505224

From angorya at openjdk.org  Fri Oct 24 18:30:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:30:22 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 23:31:01 GMT, Michael Strau?  wrote:

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

>>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>>  * map modification that would otherwise be reported as repeated invocations of the listener.
>>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>>  * reported with subsequent listener invocations.
>>  * 

>>  * 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 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 op...
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/bulk-listeners
>  - remove unused variable
>  - Don't repeatedly call backingSet.size()
>  - Separate code paths for Change/IterableChange
>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>  - Factor out IterableSetChange/IterableMapChange implementations
>  - add tests, documentation
>  - Implementation of bulk change listeners for ObservableSet and ObservableMap

What about the ordering of bulk changes?  Should it be addressed in javadoc for bulk changes (in next())?

The ordering might impact tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3444381488

From angorya at openjdk.org  Fri Oct 24 18:45:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 18:45:26 GMT
Subject: RFR: 8367439: Bulk change notifications for ObservableSet and
 ObservableMap [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 23:31:01 GMT, Michael Strau?  wrote:

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

>>  * Repeatedly calling this method allows a listener to fetch all subsequent changes of a bulk
>>  * map modification that would otherwise be reported as repeated invocations of the listener.
>>  * If the listener only fetches some of the pending changes, the rest of the changes will be
>>  * reported with subsequent listener invocations.
>>  * 

>>  * 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 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 op...
>
> 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/bulk-listeners
>  - remove unused variable
>  - Don't repeatedly call backingSet.size()
>  - Separate code paths for Change/IterableChange
>  - Use MapListenerHelper in PlatformPreferences to support bulk change notifications
>  - Factor out IterableSetChange/IterableMapChange implementations
>  - add tests, documentation
>  - Implementation of bulk change listeners for ObservableSet and ObservableMap

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 443:

> 441:             backingSet.toArray(removed);
> 442:             backingSet.clear();
> 443:             callObservers(new IterableSetChange.Remove<>(this, Arrays.asList(removed)));

suggestion:

            ArrayList removed = new ArrayList<>(backingSet);
            backingSet.clear();
            callObservers(new IterableSetChange.Remove<>(this, removed));

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1885#discussion_r2461639599

From angorya at openjdk.org  Fri Oct 24 20:19:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 24 Oct 2025 20:19:47 GMT
Subject: RFR: 8364777: RichTextArea: cursor over scrollbar
Message-ID: 

Fixes the cursor over the content area vs other parts of the `RichTextArea` and `CodeArea`.

Root cause: styling wrong thing in modena.css.

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

Commit messages:
 - cursor

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

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

From jhendrikx at openjdk.org  Sat Oct 25 09:31:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 25 Oct 2025 09:31:48 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
Message-ID: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>

This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.

See the sample program and video in the related JBS ticket.

Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.

Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

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

Commit messages:
 - Snap sizes after subtractions/additions that can introduce subtle errors

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

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

From martinfox656 at gmail.com  Sat Oct 25 15:08:20 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sat, 25 Oct 2025 17:08:20 +0200
Subject: StageStyle.EXTENDED with transparent background
In-Reply-To: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>
References: <3239F687-9FEB-4701-8075-79C38F84B7AE@gmail.com>
Message-ID: <4A04FCF2-573D-43CD-B1E6-056460435E6F@gmail.com>

An HTML attachment was scrubbed...
URL: 

From jvos at openjdk.org  Sun Oct 26 09:15:18 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 26 Oct 2025 09:15:18 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Oct 2025 15:11:05 GMT, Andy Goryachev  wrote:

> would agree that adding a whole battery of functional tests for layout is out of scope and better done as a follow-on.

I'm not sure I agree with this. Personally, I consider the battery of functional tests to be more important than the fix, so without the tests, I would be very conservative.
However, we're still relatively early in the 26 release cycle, and we won't do a 26 LTS, so risks on real-world drama's are limited. We can still revert this PR (if it got merged) and the previous one later in the 26-development phase.

I'll look into a more deterministic test scenario -- the suggestion from Andy with 3 levels make sense (although reality is much more complex, with Platform.runLater() running in between 2 pulses, and *that* is non-deterministic as it depends on processor speed etc.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3448244897

From john.hendrikx at gmail.com  Sun Oct 26 09:59:37 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 26 Oct 2025 10:59:37 +0100
Subject: JEP Proposal: Fluent Bindings for multiple observables
Message-ID: 

JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a

Hi everyone,

I'd like to propose an extension to the fluent bindings API on
ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
19 over 3 years ago.

The API currently is very powerful when dealing with a single
observable, but lacks support?when dealing with multiple observables.?
For example, let's say you want to compute a width/height ratio.? You
could write this:

??? ObservableValue ratio = width.map(w -> w / height.get());

... but you'll quickly find that such an observable will not update
itself when height changes, only when width changes.

The go-to solution for this is currently:

??? DoubleBinding ratio = new DoubleBinding() {
??????? { bind(width, height); }

??????? protected double computeValue() { return width.get() /
height.get(); }
??? }

My proposal would extend ObservableValue with a new `with` method that
returns an intermediate stage that can be easily?converted back to an
ObservableValue:

??? ObservableValue ratio = width.with(height).map((w, h) -> w /
h);? // yields a ratio that updates whenever w or h changes

Or for example:

???? ObservableValue point = x.with(y).map(Point::new);? //
yields a Point that updates whenever x or y changes

The intermediate stage would not be an observable value itself.? This
limits the API surface, and makes this proposal fairly lightweight and
much easier to implement.

Please see the JEP for the full proposal.? I look forward to your feedback!

--John



From jhendrikx at openjdk.org  Sun Oct 26 10:18:21 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 26 Oct 2025 10:18:21 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

> > would agree that adding a whole battery of functional tests for layout is out of scope and better done as a follow-on.
> 
> I'm not sure I agree with this. Personally, I consider the battery of functional tests to be more important than the fix, so without the tests, I would be very conservative. However, we're still relatively early in the 26 release cycle, and we won't do a 26 LTS, so risks on real-world drama's are limited. We can still revert this PR (if it got merged) and the previous one later in the 26-development phase.
> 
> I'll look into a more deterministic test scenario -- the suggestion from Andy with 3 levels make sense (although reality is much more complex, with Platform.runLater() running in between 2 pulses, and _that_ is non-deterministic as it depends on processor speed etc.

It would actually be much easier to create deterministic tests **after** this change (unless we're dealing with a converging layout that can sometimes happen with biased containers).  In the before situation, you should check if another pulse is scheduled after the layout pass, and execute it as well to be sure that the layout is stable.  In the after situation, this will almost never be the case and the presence of a pulse request can be asserted to be false.

In any case, I'd still recommend either reverting https://bugs.openjdk.org/browse/JDK-8364049 or combining it with this fix.  The intermediate situation is still fine for most cases, but there can be nasty surprises if left in by itself (albeit only in somewhat self-contradicting layout code).

I think having both the fixes guarded behind a system property averts most risks.  I'd recommend setting it on by default though, to get real world feedback, as I think we do want to incorporate this fix permanently if it works out.  I think it definitely much closer matches the intent of the original implementation.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3448345419

From jvos at openjdk.org  Sun Oct 26 10:32:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 26 Oct 2025 10:32:19 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 22:11:11 GMT, Andy Goryachev  wrote:

> I could write a test that will work with the old code, and fail with the new code (simple counting layout passes, or having some state that requires multiple passes would work to "detect" this fix) but am unsure what purpose that would serve.

The main purpose is testing for regression. We want to make sure a future PR does not re-introduces the old situation.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3448374015

From nlisker at gmail.com  Sun Oct 26 12:56:40 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 26 Oct 2025 14:56:40 +0200
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
Message-ID: 

When I need to combine observable values I usually do something like:

Bindings.createDoubleBinding(() ->  width.get() / height.get(), height,
width);

which is much less cumbersome than subclassing (although a bit less
performant I think). It works for an arbitrary number of observables
(including) observable lists/sets/maps too:

Bindings.createDoubleBinding(() ->  list.getFirst() / height.get() *
map.get("A"), height, list, map); // assume this makes sense somehow

ReactFX, which is the go-to library for such extension, has a 'combine'
method that work like this:

Val.combine(height, width, (h, w) -> w / h);

with overloads for up to 6 observables (with a hexafunction). For an
arbitrary number, you need the 'create' method that works very much like
the JavaFX Bindings one:

Val.create(() -> a.get() * b.get() * c.get(), a, b, c);


To assess the proposal, I tried to write your JEP examples with the current
JavaFX.

Multi-stage chain (not sure how you mapped to a Point3D from a Point2D and
a number):

ObjectBinding point2d = Bindings.createObjectBinding(() -> new
Point2D(x.get(), y.get()), x, y);
ObjectBinding point3d = Bindings.createObjectBinding(() -> new
Point3D(point2d.get().getX(), point2d.get().getY(), z.get()), point2d, z);

Combining chains:


ObjectBinding point1 = Bindings.createObjectBinding(() -> new
Point2D(x.get(), y.get()), x, y);

ObjectBinding point2 = Bindings.createObjectBinding(() -> new
Point2D(x.get(), y.get()), x, y);
ObjectBinding line = Bindings.createObjectBinding(() -> new
Line2D(point1, point2), point1, point2); // Line2D is not a JavaFX class

Using a default value:

ObservableValue point1 = Bindings.createObjectBinding(() -> new
Point2D(x.get(), y.get()), x, y).orElse(Point2D.ZERO);


Some observations:
Bindings returns a Binding rather than an ObservableValue and also has
primitive specialization versions that have their unique methods (add,
subtract...). These methods, however, can be replicated with fluent
bindings and they also have the "known" subtle GC issue for the
intermediary values.
Also, static imports can make these calls less ceremonious:
createObjectBinding(() -> new Point2D(x.get(), y.get()), x, y);

The proposal is more ergonomic with its fluency for a couple of values, but
I'm not sure it solves enough problems that the current mechanism can't.

On Sun, Oct 26, 2025 at 11:59?AM John Hendrikx 
wrote:

> JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a
>
> Hi everyone,
>
> I'd like to propose an extension to the fluent bindings API on
> ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
> 19 over 3 years ago.
>
> The API currently is very powerful when dealing with a single
> observable, but lacks support when dealing with multiple observables.
> For example, let's say you want to compute a width/height ratio.  You
> could write this:
>
>     ObservableValue ratio = width.map(w -> w / height.get());
>
> ... but you'll quickly find that such an observable will not update
> itself when height changes, only when width changes.
>
> The go-to solution for this is currently:
>
>     DoubleBinding ratio = new DoubleBinding() {
>         { bind(width, height); }
>
>         protected double computeValue() { return width.get() /
> height.get(); }
>     }
>
> My proposal would extend ObservableValue with a new `with` method that
> returns an intermediate stage that can be easily converted back to an
> ObservableValue:
>
>     ObservableValue ratio = width.with(height).map((w, h) -> w /
> h);  // yields a ratio that updates whenever w or h changes
>
> Or for example:
>
>      ObservableValue point = x.with(y).map(Point::new);  //
> yields a Point that updates whenever x or y changes
>
> The intermediate stage would not be an observable value itself.  This
> limits the API surface, and makes this proposal fairly lightweight and
> much easier to implement.
>
> Please see the JEP for the full proposal.  I look forward to your feedback!
>
> --John
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From arapte at openjdk.org  Mon Oct 27 04:50:51 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 27 Oct 2025 04:50:51 GMT
Subject: [jfx25u] RFR: 8369820: FX: Update copyright year in docs,
 readme files to 2026
Message-ID: 

Backport the change for updating copyright year in doc file for jfx25u release.

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

Commit messages:
 - doc copy year update 2026

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

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

From lkostyra at openjdk.org  Mon Oct 27 09:51:41 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 27 Oct 2025 09:51:41 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Oct 2025 14:16:02 GMT, Andy Goryachev  wrote:

> I am curious: could you tell me more about Polish/Spanish IME, what exactly have you try?

As for Spanish, the method I use is to press `'` key and then `e` key, that triggers an IME shortcut to input `?`. For Polish there is a few key combinations to get the diacritics, but since Poland most commonly uses the US keyboard layout its not always IME-dependent - I like to check them regardless though. The combos for Polish are Right Alt + A/C/E/L/N/O/X/Z - should produce ?/?/?/?/?/?/?/? respectively. Note that these combos work only in layout sometimes (ex. on Windows) called "Polish (Programmers)", There's an older layout "Polish (214)" that dates all the way back to the typewriter era, but it's now considered obsolete and almost everyone uses the former.

One more IME check I also do borrows from [this old commit replacing XIM with IBus](https://github.com/openjdk/jfx/pull/1080#discussion_r1885813314) and refers to Chinese (Pinyin) keyboard layout, simply trying to type "ni hao" - without IME this produces that exact text using latin alphabet, while with properly working IME it gets converted to respective Chinese characters.

In case of RTA, without this change Polish diacritics worked fine, but Spanish ones did not and Chinese keyboard produced latin characters. This change makes both the Spanish shortcut and Chinese character conversion work properly.

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3450395279

From arapte at openjdk.org  Mon Oct 27 10:24:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 27 Oct 2025 10:24:46 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

The method `isCurrentLayoutChild()` was introduced with the fix for [JDK-8137252](https://bugs.openjdk.org/browse/JDK-8137252).
With this PR change, the issue [JDK-8137252](https://bugs.openjdk.org/browse/JDK-8137252) recurs.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3450525690

From jhendrikx at openjdk.org  Mon Oct 27 10:24:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 10:24:46 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <2tfaL8hLheSDHfSP0Hb12PmPfy0y-x5u4PJyYJC2j38=.92c3240d-3331-49f1-9762-eea2f2b3c94f@github.com>

On Mon, 27 Oct 2025 10:19:31 GMT, Ambarish Rapte  wrote:

> The method `isCurrentLayoutChild()` was introduced with the fix for [JDK-8137252](https://bugs.openjdk.org/browse/JDK-8137252). With this PR change, the issue [JDK-8137252](https://bugs.openjdk.org/browse/JDK-8137252) recurs.

Thanks, I will have a look.  If I can resolve the issue, I'll add a test case for this problem as well so we can detect a regression more easily.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3450535717

From hmeda at openjdk.org  Mon Oct 27 11:13:05 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 27 Oct 2025 11:13:05 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes
Message-ID: 

Additional fixes for libxslt 1.1.43. Verified build and sanity.

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

Commit messages:
 - Additional libxslt 1.1.43 fixes

Changes: https://git.openjdk.org/jfx/pull/1949/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1949&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370632
  Stats: 213 lines in 3 files changed: 83 ins; 14 del; 116 mod
  Patch: https://git.openjdk.org/jfx/pull/1949.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1949/head:pull/1949

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

From jhendrikx at openjdk.org  Mon Oct 27 11:31:52 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 11:31:52 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

The fix in https://bugs.openjdk.org/browse/JDK-8137252 is only "solving" the problem because now a relayout **always** occurs (until nobody modifies layout X/Y to different values).  The `isCurrentLayoutChild` check never returns `true` for a `StackPane` or any other layout container, because they don't update the current layout child before positioning said child.  The code in `Parent::layoutChildren` is a red herring and will not apply this logic magically to all other layout containers.

So, yes, https://bugs.openjdk.org/browse/JDK-8137252 fixes the problem, but it does so at the cost of an extra layout pass in all cases.  In the sample application, even if there was only a Label in that stack pane and no Ellipse, then the first time it is laid out, it will do a 2nd pass because **Label's** layout X/Y was modified...

I'm now looking further how this problem relates to `Shape` and its subtypes, as this fix is not a problem for node types based on `Parent`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3450810439

From kcr at openjdk.org  Mon Oct 27 12:56:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 12:56:45 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 11:06:54 GMT, Hima Bindu Meda  wrote:

> Additional fixes for libxslt 1.1.43. Verified build and sanity.

Reviewers: @kevinrushforth @jaybhaskar

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

PR Comment: https://git.openjdk.org/jfx/pull/1949#issuecomment-3451142084

From kcr at openjdk.org  Mon Oct 27 13:03:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 13:03:45 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: 
References: 
Message-ID: <1Z-RYwrE2cIVTTJ3zKQ9UhYIAG8TOQG1a3J1_Kkn3LY=.03e31f63-150b-4bbc-937f-94977d03b40b@github.com>

On Mon, 27 Oct 2025 11:06:54 GMT, Hima Bindu Meda  wrote:

> Additional fixes for libxslt 1.1.43. Verified build and sanity.

LGTM. The indentation looks a little off in a couple places, so you might want to check it. I'll reapprove if you make any changes.

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/transform.c line 2604:

> 2602:             * Cleanup temporary tree fragments.
> 2603:             */
> 2604:                     if (oldLocalFragmentTop != ctxt->localRVTList)

Indentation is off.

modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt/transform.c line 5329:

> 5327:     * "select" expression.
> 5328:     */
> 5329:         if (oldLocalFragmentTop != ctxt->localRVTList)

Indentation

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1949#pullrequestreview-3383279562
PR Review Comment: https://git.openjdk.org/jfx/pull/1949#discussion_r2465504756
PR Review Comment: https://git.openjdk.org/jfx/pull/1949#discussion_r2465506067

From hmeda at openjdk.org  Mon Oct 27 13:22:01 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 27 Oct 2025 13:22:01 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes [v2]
In-Reply-To: 
References: 
Message-ID: 

> Additional fixes for libxslt 1.1.43. Verified build and sanity.

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  correct indentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1949/files
  - new: https://git.openjdk.org/jfx/pull/1949/files/3c499da9..1084f7ff

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

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

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

From jhendrikx at openjdk.org  Mon Oct 27 14:12:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 14:12:00 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

So I've been playing with the program in https://bugs.openjdk.org/browse/JDK-8137252 and here are some observations:

- It is binding width/height of a sibling to another (size altering) property of another sibling.  This is questionable practice, especially when both siblings are **managed** and part of a container that uses managed children (StackPane in this case).  You get away with this because `Shape`s are not resizable (by the standard width/height mechanism), and so the container can't force its a preferred size onto a `Shape`.  If it was anything else (like a Region or Button) then after changing the size, relayout would run, and your change would be overridden, at least, until you set that control to unmanaged.

- Because containers do not resize non-resizable controls, but do set their positions, this is a very special half managed/half unmanaged territory.

- The whole thing works by doing a **2nd** layout pass.  This means that when you modify the width/height of the source sibling, that this will trigger a first layout pass.  During the layout pass, you modify the values of the destination sibling.  This then requires another layout pass.  Two layout passes aside, this will show up on your screen as the **layout "jumping"** (ie. it shows the destination sibling first in the wrong position, then in the 2nd pass it corrects this).  I don't see why anyone would want to do it this way, as this will make the layout jump.  In fact, if you go further, and bind more properties in these ways, you can get a 3rd layout pass, and a 4th etc.  This is not a good solution.

Currently, on each change (showing the stage, changing the source sibling's size) we see the layoutX of the destination sibling jumping:

          lx = 0.0
          Showing scene
          lx = 9.333332697550457
          lx = 17.99999936421712
          Triggering 2nd change
          lx = 17.333334604899086
          lx = 34.00000127156576
          
> What's the correct way then to draw a circle around a label that doesn't make your layout jump?

The wanted solution does not make it easy.  Because the label's width is used as radius, the desired circle actually is twice as wide as the label.  The stack pane however is unaware of this requirement as the circle is not resizable and does not have min/pref/max properties.  It has some similarities with solutions that must know the size of text (in the correct font after CSS has been applied) because other elements depend on it.

The solution is to add a listener to the label's `needsLayoutProperty` (which BTW is undocumented but public since 2012).  Every time something of consequence changes on the Label, one can now calculate how large the circle should be.  It is a bit more involved, but you get a **single** layout pass, and there is no UI jumping anymore:


public class Test1 extends Application {

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

    @Override
    public void start(Stage stage) {

        Label l1 = new Label("1 2");
        Ellipse e1 = new Ellipse(100, 50);
        StackPane sp = new StackPane(l1, new EllipseWrapper(l1));

        e1.setOpacity(0.5);
        sp.relocate(200, 100);

        Pane topPane = new Pane(sp);
        Scene scene = new Scene(topPane, 600, 400);

        sp.setStyle("-fx-border-color: RED;");

        stage.setScene(scene);
        System.out.println("Showing scene");

        stage.show();

        Thread.ofVirtual().start(() -> {
          for(;;) {
            try {
              Thread.sleep(1500);
            }
            catch(InterruptedException e) {
              break;
            }

            Platform.runLater(() -> {
              l1.setText("" + (int)(2000 * Math.random()));
            });
          }
        });
    }

    // wrapper because Ellipse has no layout properties for StackPane to use:
    class EllipseWrapper extends Region {
      private final Ellipse ellipse = new Ellipse();
      private final Label label;

      public EllipseWrapper(Label label) {
          this.label = label;
          ellipse.setOpacity(0.5);
          getChildren().add(ellipse);

          // using a change listener to ensure property is revalidated:
          label.needsLayoutProperty().subscribe(v -> requestLayout());
      }

      @Override
      protected double computePrefWidth(double height) {
          return 2 * label.prefWidth(-1);  // proper calculation for layout!
      }

      @Override
      protected double computePrefHeight(double width) {
          return 2 * label.prefHeight(-1);
      }

      @Override
      protected void layoutChildren() {
          double w = getWidth();
          double h = getHeight();
          ellipse.setRadiusX(w / 2);
          ellipse.setRadiusY(h / 2);
          ellipse.setCenterX(w / 2);
          ellipse.setCenterY(h / 2);
      }
  }
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3451483699

From jhendrikx at openjdk.org  Mon Oct 27 14:25:02 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 14:25:02 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 16:55:32 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ToolBarSkinTest
>   
>   Reusing a toolbar as part of several scenes, in combination with the StubToolkit that doesn't handle pulses makes this test fail with the relayout detection fix.

IMHO there are now two ways forward:

1. We wish to support this rather odd program in https://bugs.openjdk.org/browse/JDK-8137252 despite it **requiring** two layout passes (with a visible UI jump).  This is possible by allowing only non-resizable containers to unconditionally trigger the relayout logic (instead of having everything trigger it because of the current disfunctional `isCurrentLayoutChild` logic):

                    if (!isResizable() || (p != null && !p.inLayoutChildren())) {

2. We don't want to support this, as IMHO, it is bad practice to bind to layout properties as this will inevitably lead to multiple layout passes and jumps (which makes JavaFX UI's appear flakey).

I've already written a couple of tests that nicely capture the advantage of this fix.  The tests clearly show that only one layout pass now occurs with this fix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3451549609

From jhendrikx at openjdk.org  Mon Oct 27 14:31:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 14:31:30 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v3]
In-Reply-To: 
References: 
Message-ID: 

> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

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

  Add regression test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1945/files
  - new: https://git.openjdk.org/jfx/pull/1945/files/a22ce090..79296325

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

  Stats: 141 lines in 1 file changed: 112 ins; 8 del; 21 mod
  Patch: https://git.openjdk.org/jfx/pull/1945.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1945/head:pull/1945

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

From jhendrikx at openjdk.org  Mon Oct 27 14:44:44 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Oct 2025 14:44:44 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
Message-ID: 

> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.

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

  Rename test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1945/files
  - new: https://git.openjdk.org/jfx/pull/1945/files/79296325..8d496e9c

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

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

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

From arapte at openjdk.org  Mon Oct 27 15:44:54 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 27 Oct 2025 15:44:54 GMT
Subject: [jfx25u] Integrated: 8369820: FX: Update copyright year in docs,
 readme files to 2026
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 04:29:09 GMT, Ambarish Rapte  wrote:

> Backport the change for updating copyright year in doc file for jfx25u release.

This pull request has now been integrated.

Changeset: f710000f
Author:    Ambarish Rapte 
URL:       https://git.openjdk.org/jfx25u/commit/f710000f99e1f4fe3cc55c160c0aa536bd79a5d4
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8369820: FX: Update copyright year in docs, readme files to 2026

Backport-of: 47d9dcc38a5e685a014774274f478b4205c6e397

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

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

From angorya at openjdk.org  Mon Oct 27 19:47:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Oct 2025 19:47:22 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
Message-ID: <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

First of all, I would like to thank you John for looking into the layout problems.  We've got these long standing issues that are very difficult to debug and fix.

I think this is valuable work as it definitely improves the platform, so Danke sch?n.

The reason I asked about tests and test scenarios is the possibility of regression.  Case in point - with this PR, on macOS with an external monitor at scale=1:

Image

I would second @johanvos in suggesting that the regression is what we should be guarding against, and perhaps expanding the tests.

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

> 1288:                     layoutChildren();
> 1289:                 }
> 1290:                 finally {

minor suggestion:
`} finally {`

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

PR Review: https://git.openjdk.org/jfx/pull/1945#pullrequestreview-3385140013
PR Review Comment: https://git.openjdk.org/jfx/pull/1945#discussion_r2466840973

From andy.goryachev at oracle.com  Mon Oct 27 19:48:43 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 27 Oct 2025 19:48:43 +0000
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
Message-ID: 

Doesn't

DoubleBinding createDoubleBinding(final Callable func, final Observable... dependencies)

handles the use case you describe?

-andy

From: openjfx-dev  on behalf of John Hendrikx 
Date: Sunday, October 26, 2025 at 02:59
To: openjfx-dev 
Subject: JEP Proposal: Fluent Bindings for multiple observables

JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a

Hi everyone,

I'd like to propose an extension to the fluent bindings API on
ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
19 over 3 years ago.

The API currently is very powerful when dealing with a single
observable, but lacks support when dealing with multiple observables.
For example, let's say you want to compute a width/height ratio.  You
could write this:

    ObservableValue ratio = width.map(w -> w / height.get());

... but you'll quickly find that such an observable will not update
itself when height changes, only when width changes.

The go-to solution for this is currently:

    DoubleBinding ratio = new DoubleBinding() {
        { bind(width, height); }

        protected double computeValue() { return width.get() /
height.get(); }
    }

My proposal would extend ObservableValue with a new `with` method that
returns an intermediate stage that can be easily converted back to an
ObservableValue:

    ObservableValue ratio = width.with(height).map((w, h) -> w /
h);  // yields a ratio that updates whenever w or h changes

Or for example:

     ObservableValue point = x.with(y).map(Point::new);  //
yields a Point that updates whenever x or y changes

The intermediate stage would not be an observable value itself.  This
limits the API surface, and makes this proposal fairly lightweight and
much easier to implement.

Please see the JEP for the full proposal.  I look forward to your feedback!

--John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Mon Oct 27 19:57:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Oct 2025 19:57:21 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
Message-ID: 

On Sat, 25 Oct 2025 09:26:33 GMT, John Hendrikx  wrote:

> This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.
> 
> See the sample program and video in the related JBS ticket.
> 
> Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.
> 
> Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

@hjohn is absolutely right here.  The fix is simple enough, perhaps 1 reviewer is enough (I'll take a look).  @kevinrushforth do you think we'd need a unit test for this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1948#issuecomment-3453061751

From angorya at openjdk.org  Mon Oct 27 20:19:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Oct 2025 20:19:19 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
Message-ID: 

On Sat, 25 Oct 2025 09:26:33 GMT, John Hendrikx  wrote:

> This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.
> 
> See the sample program and video in the related JBS ticket.
> 
> Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.
> 
> Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

This PR makes a change in `Control`, so it is not a localized change as it impacts all the controls.

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

PR Comment: https://git.openjdk.org/jfx/pull/1948#issuecomment-3453135307

From angorya at openjdk.org  Mon Oct 27 20:32:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Oct 2025 20:32:43 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text
Message-ID: 

User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):

When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.

Root cause: implementation bug.

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

Commit messages:
 - wrong style

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

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

From angorya at openjdk.org  Mon Oct 27 21:51:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Oct 2025 21:51:20 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
Message-ID: 

On Sat, 25 Oct 2025 09:26:33 GMT, John Hendrikx  wrote:

> This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.
> 
> See the sample program and video in the related JBS ticket.
> 
> Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.
> 
> Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

Thank you, @hjohn !

I think this is the right approach; the chance of regression is likely to be low, despite the change impacting all the controls.

A side note: as a rule, we could probably snap just the final result, even considering small floating point errors that accumulate in the intermediate computation.  For example, let's estimate a rather unlikely case of a table with 1000 columns of 1000 pixels each.  `Math.ulp(1000.0) = 1.1368683772161603E-13`, so the possible error multiplied by 1000 is still < `2E-10`.  As long as we snap the result (or when a comparison is performed), we should be ok.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1948#pullrequestreview-3385585071

From kcr at openjdk.org  Mon Oct 27 22:17:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 22:17:19 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes [v2]
In-Reply-To: 
References: 
 
Message-ID: <0gO-pi9eeGS5UYt8IfTPTgVzQzxf8LwPIF_opKG2Tt8=.ebfc53db-bfc3-44e6-988b-ee1fcbaf36b0@github.com>

On Mon, 27 Oct 2025 13:22:01 GMT, Hima Bindu Meda  wrote:

>> Additional fixes for libxslt 1.1.43. Verified build and sanity.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct indentation

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1949#pullrequestreview-3385638687

From kcr at openjdk.org  Mon Oct 27 22:21:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 22:21:17 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
Message-ID: <1-z-Mpms_bD1XJSCSsDQDuHmfs3KSCnYmOomAgeBay0=.c4c18357-e928-4e9b-bf61-e32e9146c3db@github.com>

On Sat, 25 Oct 2025 09:26:33 GMT, John Hendrikx  wrote:

> This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.
> 
> See the sample program and video in the related JBS ticket.
> 
> Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.
> 
> Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

LGTM. If you do decide to add a test, I'll reapprove.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1948#pullrequestreview-3385651048

From kcr at openjdk.org  Mon Oct 27 22:21:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 22:21:18 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: 
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
 
Message-ID: <2BwGaK7_Han1kZr7LSlVcKPjbeVKRXdSkNvWrRBodkQ=.a9c8c055-95a1-4da3-b597-ee0224fdd70f@github.com>

On Mon, 27 Oct 2025 19:55:11 GMT, Andy Goryachev  wrote:

> @hjohn is absolutely right here. The fix is simple enough, perhaps 1 reviewer is enough (I'll take a look). @kevinrushforth do you think we'd need a unit test for this PR?

It is a simple fix. I think it is OK without a unit test (although a test couldn't hurt).

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

PR Comment: https://git.openjdk.org/jfx/pull/1948#issuecomment-3453542021

From hmeda at openjdk.org  Tue Oct 28 02:33:49 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 28 Oct 2025 02:33:49 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes [v3]
In-Reply-To: 
References: 
Message-ID: <2snjJO6pdQjl5nxhJHvOptUno2h55LWcz_XIwQPYMCg=.6863bf9a-46ba-49c5-a217-744225a36905@github.com>

> Additional fixes for libxslt 1.1.43. Verified build and sanity.

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  correct indentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1949/files
  - new: https://git.openjdk.org/jfx/pull/1949/files/1084f7ff..2e2f74e3

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

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

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

From kcr at openjdk.org  Tue Oct 28 03:10:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Oct 2025 03:10:20 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes [v3]
In-Reply-To: <2snjJO6pdQjl5nxhJHvOptUno2h55LWcz_XIwQPYMCg=.6863bf9a-46ba-49c5-a217-744225a36905@github.com>
References: 
 <2snjJO6pdQjl5nxhJHvOptUno2h55LWcz_XIwQPYMCg=.6863bf9a-46ba-49c5-a217-744225a36905@github.com>
Message-ID: 

On Tue, 28 Oct 2025 02:33:49 GMT, Hima Bindu Meda  wrote:

>> Additional fixes for libxslt 1.1.43. Verified build and sanity.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct indentation

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1949#pullrequestreview-3386387774

From jhendrikx at openjdk.org  Tue Oct 28 07:20:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Oct 2025 07:20:23 GMT
Subject: RFR: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding errors
In-Reply-To: 
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
 
Message-ID: <9mxHwRKE4g57F_PLcXYRWO7I2Vjc2sF6CnPcODbTN1k=.175dd5d9-21fc-48f3-9958-b3f6c8d52504@github.com>

On Mon, 27 Oct 2025 21:48:44 GMT, Andy Goryachev  wrote:

> Thank you, @hjohn !
> 
> I think this is the right approach; the chance of regression is likely to be low, despite the change impacting all the controls.
> 
> A side note: as a rule, we could probably snap just the final result, even considering small floating point errors that accumulate in the intermediate computation. For example, let's estimate a rather unlikely case of a table with 1000 columns of 1000 pixels each. `Math.ulp(1000.0) = 1.1368683772161603E-13`, so the possible error multiplied by 1000 is still < `2E-10`. As long as we snap the result (or when a comparison is performed), we should be ok.

I considered doing that in `ScrollPaneSkin` but I prefer to find the root cause of these problems.  The fix in `Control` can fix other problems as well, and is highly unlikely to cause new problems.  If anything it shows once again how hard it is to reason about float values, but at least we now know that a resnap of the final value is **always** required.  This will help when reviewing layout code or when fixing issues.

We could consider a broad review of code that works with snapped values, and make sure values which use snapping are always resnapped before returning them.

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

PR Comment: https://git.openjdk.org/jfx/pull/1948#issuecomment-3454947142

From jhendrikx at openjdk.org  Tue Oct 28 07:31:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Oct 2025 07:31:23 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
Message-ID: 

On Mon, 27 Oct 2025 19:44:40 GMT, Andy Goryachev  wrote:

> First of all, I would like to thank you John for looking into the layout problems. We've got these long standing issues that are very difficult to debug and fix.
> 
> I think this is valuable work as it definitely improves the platform, so Danke sch?n.
> 
> The reason I asked about tests and test scenarios is the possibility of regression. Case in point - with this PR, on macOS with an external monitor at scale=1:

It is starting to look like there may be more code relying on double layouts than I thought, even though most controls work absolutely fine.  I think that it is still worth pursuing eliminating the need for these (as you can temporarily see the "wrong" positions), but it may take longer as each of these will need an investigation.

I remain convinced though that the original fix in https://bugs.openjdk.org/browse/JDK-8137252 was applied too hastily, and only worked because it, unintentionally, simply always allowed double layouts.

I'll see if I can reproduce the menu issue and what is the culprit there.  I'm not on Mac though, so hoping that the problem is also present on other platforms.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3454983522

From john.hendrikx at gmail.com  Tue Oct 28 08:06:23 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 28 Oct 2025 09:06:23 +0100
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
 
Message-ID: 

You are right, I did use an even older style, guess that shows how
rarely I even look at the `Bindings` class these days as almost
everything can be done fluently now.

The JEP I propose is specifically to fill a gap in the fluent bindings,
but that doesn't mean this is currently impossible to achieve.? It is
similar to how `map` basically can replace 50% of the methods in
`Bindings` and how `flatMap` replaces all the `select` methods.

The reason I'm proposing it is to make fluent bindings possible with
more than one source.? I mean, I can do this:

???? Property point = ...;

? ?? label.textProperty().bind(point.map(p -> "x: " + p.getX() + ", y: "
+ p.getY()));

But when the things I need are stored in multiple properties, `map`
becomes useless:

???? IntegerProperty xpos = ... ;
???? IntegerProperty ypos = ... ;

???? // can't use `map` on `xpos` or `ypos` as it would only react if
one of these properties change

In the proposal, it would become possible to observe and react to
multiple sources:

???? xpos.with(ypos).map((x, y) -> "x: " + x + ", y: " + y);

I've limited the proposal to two sources as this is sufficient to scale
to an arbitrary number, albeit with additional mapping steps.? It is
however open ended and can be extended to more than 2 sources easily
(which is something open for discussion or possible as an extension
later).? In other words, by adding another helper interface we can also
have:

???? xpos.with(ypos, zpos).map((x, y, z) -> ... );

In its most basic form however, two sources will also work:
?
???? xpos.with(ypos).map(Point2D::new).with(zpos).map((p, z) -> ... );

I think supporting two sources will cover 80% of the cases without
requiring additional mapping steps, and that quickly approaches 100%
when you potentially allow for 3 or 4 sources.

--John

On 27/10/2025 20:48, Andy Goryachev wrote:
> Doesn't?
>
> DoubleBinding createDoubleBinding(final?Callable func,
> final?Observable... dependencies)
>
> handles the use case you describe?
>
> -andy
>
> *From: *openjfx-dev  on behalf of John
> Hendrikx 
> *Date: *Sunday, October 26, 2025 at 02:59
> *To: *openjfx-dev 
> *Subject: *JEP Proposal: Fluent Bindings for multiple observables
>
> JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a
>
> Hi everyone,
>
> I'd like to propose an extension to the fluent bindings API on
> ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
> 19 over 3 years ago.
>
> The API currently is very powerful when dealing with a single
> observable, but lacks support?when dealing with multiple observables.?
> For example, let's say you want to compute a width/height ratio.? You
> could write this:
>
> ??? ObservableValue ratio = width.map(w -> w / height.get());
>
> ... but you'll quickly find that such an observable will not update
> itself when height changes, only when width changes.
>
> The go-to solution for this is currently:
>
> ??? DoubleBinding ratio = new DoubleBinding() {
> ??????? { bind(width, height); }
>
> ??????? protected double computeValue() { return width.get() /
> height.get(); }
> ??? }
>
> My proposal would extend ObservableValue with a new `with` method that
> returns an intermediate stage that can be easily?converted back to an
> ObservableValue:
>
> ??? ObservableValue ratio = width.with(height).map((w, h) -> w /
> h);? // yields a ratio that updates whenever w or h changes
>
> Or for example:
>
> ???? ObservableValue point = x.with(y).map(Point::new);? //
> yields a Point that updates whenever x or y changes
>
> The intermediate stage would not be an observable value itself.? This
> limits the API surface, and makes this proposal fairly lightweight and
> much easier to implement.
>
> Please see the JEP for the full proposal.? I look forward to your
> feedback!
>
> --John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jbhaskar at openjdk.org  Tue Oct 28 08:10:21 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 28 Oct 2025 08:10:21 GMT
Subject: RFR: 8370632: Additional libxslt 1.1.43 fixes [v3]
In-Reply-To: <2snjJO6pdQjl5nxhJHvOptUno2h55LWcz_XIwQPYMCg=.6863bf9a-46ba-49c5-a217-744225a36905@github.com>
References: 
 <2snjJO6pdQjl5nxhJHvOptUno2h55LWcz_XIwQPYMCg=.6863bf9a-46ba-49c5-a217-744225a36905@github.com>
Message-ID: 

On Tue, 28 Oct 2025 02:33:49 GMT, Hima Bindu Meda  wrote:

>> Additional fixes for libxslt 1.1.43. Verified build and sanity.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct indentation

Looks good to me

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1949#pullrequestreview-3387201686

From john.hendrikx at gmail.com  Tue Oct 28 08:28:13 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 28 Oct 2025 09:28:13 +0100
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
 
Message-ID: <6daf355b-0b94-442f-8e1a-bc52a51283e3@gmail.com>

Thanks for taking a look Nir, I really appreciate it :)

On 26/10/2025 13:56, Nir Lisker wrote:
> When I need to combine observable values I usually do something like:
>
> Bindings.createDoubleBinding(() ->? width.get() / height.get(),
> height, width);
>
> which is much less cumbersome than subclassing (although a bit less
> performant I think). It works for an arbitrary number of observables
> (including) observable lists/sets/maps too:

You're right, I forgot about the existence of the Bindings class, and
the helpers it has added for these cases.? I barely use it since the
addition of fluent bindings.? That version is a lot more compact and a
bit more workable.

>
> Bindings.createDoubleBinding(() ->? list.getFirst() / height.get() *
> map.get("A"), height, list, map); // assume this makes sense somehow
>
> ReactFX, which is the go-to library for such extension, has a
> 'combine' method that work like this:
>
> Val.combine(height, width, (h, w) -> w / h);

I'm aware of this, and it is something to be considered as an addition.?
It is similar to the argument where there is a `Subscription.combine`
and `subscription.and`, one being static and the other being a fluent
method.? I think however we shouldn't be relying on ReactFX too much
anymore these days (I haven't used it in years now).? The primary reason
for that is that ReactFX had to introduce new property classes which are
limited in how well they can interop with existing JavaFX code.? With
the fluent bindings additions the need for ReactFX is limited.? That is
not to say ReactFX doesn't offer anything interesting anymore :)

> To assess the proposal, I tried to write your JEP examples with the
> current JavaFX.
>
> Multi-stage chain (not sure how you mapped to a Point3D from a Point2D
> and a number):
>
> ObjectBinding point2d = Bindings.createObjectBinding(() ->
> new Point2D(x.get(), y.get()), x, y);
> ObjectBinding point3d = Bindings.createObjectBinding(() ->
> new Point3D(point2d.get().getX(), point2d.get().getY(), z.get()),
> point2d, z);
>
> Combining chains:
>
>
> ObjectBinding point1 = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y);
>
> ObjectBinding point2 = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y);
> ObjectBinding line = Bindings.createObjectBinding(() -> new
> Line2D(point1, point2), point1, point2); // Line2D is not a JavaFX class
>
>
> Using a default value:
>
> ObservableValue point1 = Bindings.createObjectBinding(() ->
> new Point2D(x.get(), y.get()), x, y).orElse(Point2D.ZERO);
>
>
> Some observations:
> Bindings returns a Binding rather than an ObservableValue and also has
> primitive specialization versions that have their unique methods (add,
> subtract...). These methods, however, can be replicated with fluent
> bindings and they also have the "known" subtle GC issue for the
> intermediary values.
Yes, I don't think we should cater to primitive specializations.
Bindings tend to be high level enough (often eventually tied to a UI)
that it makes little sense to "optimize" these at the cost of 8x more
variants. The GC issues are often insidious, and my problems in that
area have largely disappeared with the addition of the fluent bindings
and subscribe API's.? This is why I'm hesitant to use API's from the
Bindings class, and why I think FX should offer alternatives in that area.
> Also, static imports can make these calls less ceremonious:
> createObjectBinding(() -> new Point2D(x.get(), y.get()), x, y);
Static imports are not really a plus for any argument in my view :)?
Compare AssertJ and Hamcrest to see what I mean.
>
> The proposal is more ergonomic with?its?fluency for a couple of
> values, but I'm not sure it solves enough problems that the current
> mechanism can't.

It is an extension on the fluent API, it doesn't introduce anything that
isn't possible currently, just like `map` and `flatMap` didn't introduce
anything new, nor did `subscribe`.? It is intended to be a more
discoverable, fluent and modern API, and to fill a gap where one has to
go from the fluent binding model to a static helper class model as soon
as you go from mapping just one source to needing two or more sources.

--John

>
> On Sun, Oct 26, 2025 at 11:59?AM John Hendrikx
>  wrote:
>
>     JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a
>
>     Hi everyone,
>
>     I'd like to propose an extension to the fluent bindings API on
>     ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
>     19 over 3 years ago.
>
>     The API currently is very powerful when dealing with a single
>     observable, but lacks support?when dealing with multiple observables.?
>     For example, let's say you want to compute a width/height ratio.? You
>     could write this:
>
>     ??? ObservableValue ratio = width.map(w -> w / height.get());
>
>     ... but you'll quickly find that such an observable will not update
>     itself when height changes, only when width changes.
>
>     The go-to solution for this is currently:
>
>     ??? DoubleBinding ratio = new DoubleBinding() {
>     ??????? { bind(width, height); }
>
>     ??????? protected double computeValue() { return width.get() /
>     height.get(); }
>     ??? }
>
>     My proposal would extend ObservableValue with a new `with` method that
>     returns an intermediate stage that can be easily?converted back to an
>     ObservableValue:
>
>     ??? ObservableValue ratio = width.with(height).map((w, h)
>     -> w /
>     h);? // yields a ratio that updates whenever w or h changes
>
>     Or for example:
>
>     ???? ObservableValue point = x.with(y).map(Point::new);? //
>     yields a Point that updates whenever x or y changes
>
>     The intermediate stage would not be an observable value itself.? This
>     limits the API surface, and makes this proposal fairly lightweight and
>     much easier to implement.
>
>     Please see the JEP for the full proposal.? I look forward to your
>     feedback!
>
>     --John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvos at openjdk.org  Tue Oct 28 08:28:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 28 Oct 2025 08:28:22 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
Message-ID: <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>

On Tue, 28 Oct 2025 07:28:25 GMT, John Hendrikx  wrote:

> It is starting to look like there may be more code relying on double layouts than I thought, even though most controls work absolutely fine. I think that it is still worth pursuing eliminating the need for these (as you can temporarily see the "wrong" positions), but it may take longer as each of these will need an investigation.
> 
> I remain convinced though that the original fix in https://bugs.openjdk.org/browse/JDK-8137252 was applied too hastily, and only worked because it, unintentionally, simply always allowed double layouts.

That is very well possible, but it is what it is. I believe the main goal of the layout phase in a pulse is to make sure that "ultimately", all direct/indirect requests are handled. The secondary goal is that it should be done as efficient as possible, e.g. do not require 2 (or more) passes unless absolutely needed. 
The issue is, though, that there are a huge amount of possible scenarios, leading to situations that can not be dealt with by a single, optimized flow. I started documenting and analyzing scenarios, and even a very basic 2 node case poses issues that can go wrong.
Looking at it with our openjfx glasses, some of these scenarios are really bad. However, developers without internal knowledge often have no idea how and why it can go wrong. Adding bindings/listeners between siblings is a very common pattern, and when looking at my old code, I made tons of "mistakes" by having too much bindings that asked the layout phase to solve an almost impossible job. 
At least the layout system in JavaFX gives developers lots of freedom, and it promises to handle all edge cases. That fulfills the main goal (correct rendering, perhaps after a number of pulses, leading to flickering), but it makes the second goal (top-efficiency) really hard.

To make it harder (but very understandable), the layout phase spans a number of classes, where different concepts/choices are made (e.g. both Parent and Node have internal state that is used to determine whether to initiate a new pulse). That makes it really hard to come up with a system that would typically be used in these situations: use an algorithm that always works (although maybe less performant), and use optimizations in specific cases (e.g. no bindings in properties of children in a chontainer -> use this branch).

Something I've been thinking about every now and then is to introduce runtime warnings (ideally compiler *errors*, but that would require lots of upfront analysis), where the layout subsystem can warn that "a pretty complex situation occurred", e.g. when it is running into cyclic conditions that are not trivial to resolve without performance degradation. But that would be a major effort and conceptual change.

TLDR: I feel your pain and it can be very frustrating having to deal with non-optimal but valid code, deployed in the wild.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3455150271

From lkostyra at openjdk.org  Tue Oct 28 11:26:19 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 28 Oct 2025 11:26:19 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 18 Sep 2025 15:47:03 GMT, Martin Fox  wrote:

> 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 played around with this for a bit and I cannot reproduce this behavior. When I start the app it gets brought to foreground and stage.isFocused() returns true as it should for me.

Could it be the difference between Windows versions maybe? I'm running Win 11 24H2 at this point in time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3455972567

From lkostyra at openjdk.org  Tue Oct 28 11:33:43 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 28 Oct 2025 11:33:43 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus [v2]
In-Reply-To: 
References: 
Message-ID: 

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

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

 - Merge remote-tracking branch 'origin/master' into isFocused_fix-8359899
 - Adjust window focus management for Windows Glass

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1849/files
  - new: https://git.openjdk.org/jfx/pull/1849/files/f8a575e4..00c2d60e

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

  Stats: 904516 lines in 10126 files changed: 386268 ins; 394150 del; 124098 mod
  Patch: https://git.openjdk.org/jfx/pull/1849.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1849/head:pull/1849

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

From hmeda at openjdk.org  Tue Oct 28 12:12:23 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 28 Oct 2025 12:12:23 GMT
Subject: Integrated: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 11:06:54 GMT, Hima Bindu Meda  wrote:

> Additional fixes for libxslt 1.1.43. Verified build and sanity.

This pull request has now been integrated.

Changeset: 478e1ad4
Author:    Hima Bindu Meda 
URL:       https://git.openjdk.org/jfx/commit/478e1ad43b2feaa4fa1d5be656b78cadf2316ba3
Stats:     215 lines in 3 files changed: 83 ins; 14 del; 118 mod

8370632: Additional libxslt 1.1.43 fixes

Reviewed-by: kcr, jbhaskar

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

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

From hmeda at openjdk.org  Tue Oct 28 13:52:23 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 28 Oct 2025 13:52:23 GMT
Subject: [jfx25u] RFR: 8370632: Additional libxslt 1.1.43 fixes
Message-ID: <4lmCwzyqge1QBnC4_xrhhKv4JeBzMkzVEOY0zYchHgM=.e7a76931-e35e-4378-a7f8-717c11a14376@github.com>

clean Backport

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

Commit messages:
 - Backport 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

Changes: https://git.openjdk.org/jfx25u/pull/28/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=28&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370632
  Stats: 215 lines in 3 files changed: 83 ins; 14 del; 118 mod
  Patch: https://git.openjdk.org/jfx25u/pull/28.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/28/head:pull/28

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

From hmeda at openjdk.org  Tue Oct 28 14:59:26 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 28 Oct 2025 14:59:26 GMT
Subject: [jfx25u] Integrated: 8370632: Additional libxslt 1.1.43 fixes
In-Reply-To: <4lmCwzyqge1QBnC4_xrhhKv4JeBzMkzVEOY0zYchHgM=.e7a76931-e35e-4378-a7f8-717c11a14376@github.com>
References: <4lmCwzyqge1QBnC4_xrhhKv4JeBzMkzVEOY0zYchHgM=.e7a76931-e35e-4378-a7f8-717c11a14376@github.com>
Message-ID: 

On Tue, 28 Oct 2025 13:45:21 GMT, Hima Bindu Meda  wrote:

> clean Backport

This pull request has now been integrated.

Changeset: 2d807883
Author:    Hima Bindu Meda 
URL:       https://git.openjdk.org/jfx25u/commit/2d8078836ce9367ad0c6aad84587d9b8875b4efd
Stats:     215 lines in 3 files changed: 83 ins; 14 del; 118 mod

8370632: Additional libxslt 1.1.43 fixes

Backport-of: 478e1ad43b2feaa4fa1d5be656b78cadf2316ba3

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

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

From angorya at openjdk.org  Tue Oct 28 15:42:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 15:42:49 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
Message-ID: 

On Tue, 28 Oct 2025 07:28:25 GMT, John Hendrikx  wrote:

> I'll see if I can reproduce the menu issue and what is the culprit there.

Thanks!  For what it's worth, the issue also appears when I move the window from the main retina screen (scale=2) to an external monitor (scale=1).  I would imagine it should be easy to reproduce on Windows, especially with a fractional scale.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457147026

From angorya at openjdk.org  Tue Oct 28 15:58:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 15:58:09 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
Message-ID: 

On Tue, 28 Oct 2025 08:25:58 GMT, Johan Vos  wrote:

> That fulfills the main goal (correct rendering, perhaps after a number of pulses, leading to flickering), but it makes the second goal (top-efficiency) really hard.

I might be way off, but I wanted to ask you this:

How many pulses are needed to finish the layout?  If we ignore for a second some pathological cases when the layout process never ends causing continuous flicker, is there a safe upper limit?

What I am getting at is - what if we run more than one layout pass (`Scene::doLayoutPass`) per pulse?  In other words, if the layout is still dirty, we keep doing the layout until it's settled, without the associated re-rendering and flicker, and if it's still dirty after N cycles we print a warning (if said warning is enabled)?

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457215288

From lkostyra at openjdk.org  Tue Oct 28 16:08:21 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 28 Oct 2025 16:08:21 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext
Message-ID: 

This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.

On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.

This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

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

Commit messages:
 - Add isValid checks to D3DTexture.update()

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

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

From jhendrikx at openjdk.org  Tue Oct 28 16:54:24 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Oct 2025 16:54:24 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
Message-ID: 

On Tue, 28 Oct 2025 15:55:09 GMT, Andy Goryachev  wrote:

> > That fulfills the main goal (correct rendering, perhaps after a number of pulses, leading to flickering), but it makes the second goal (top-efficiency) really hard.
> 
> I might be way off, but I wanted to ask you this:
> 
> How many pulses are needed to finish the layout? If we ignore for a second some pathological cases when the layout process never ends causing continuous flicker, is there a safe upper limit?
> 
> What I am getting at is - what if we run more than one layout pass (`Scene::doLayoutPass`) per pulse? In other words, if the layout is still dirty, we keep doing the layout until it's settled, without the associated re-rendering and flicker, and if it's still dirty after N cycles we print a warning (if said warning is enabled)?
> 
> What do you think?

It's not a bad idea to just run layout again if after running layout the root is still dirty.  That would kill the flicker, but would just reinforce bad patterns.  Also, the CPU cost is still there (ie. if you resize a Window with say a large complex tableview, then it will still have to do a whole lot of calculations twice, while the 2nd run basically changes nothing).

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457492519

From angorya at openjdk.org  Tue Oct 28 17:03:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 17:03:08 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
Message-ID: <11zeIm7vBa0XUqZohlVZWDBxYsHLIfr4IkAIlxKzqMY=.b8b31296-d6ff-4611-95c2-e31f9d6a9129@github.com>

On Tue, 28 Oct 2025 16:51:35 GMT, John Hendrikx  wrote:

> Also, the CPU cost is still there

that's true, but the cost will be there anyway - but now we are skipping the rendering and removing the flicker.  So it's a win-win, as long as the layout converges.

One example is when the layout must further change based on the current layout pass, such as when the scroll bar appears or disappears.

Also, doing these burst micro-layouts might be independent of any other work we are doing in terms of removing "bad patters" (the scroll bar scenario above is not really a bad pattern on itself, just a fact of life, I think).

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457533655

From jvos at openjdk.org  Tue Oct 28 17:12:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 28 Oct 2025 17:12:06 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
Message-ID: 

On Tue, 28 Oct 2025 16:51:35 GMT, John Hendrikx  wrote:

> How many pulses are needed to finish the layout? If we ignore for a second some pathological cases when the layout process never ends causing continuous flicker, is there a safe upper limit?

Realistically, I'd say 10 iterations is pretty common, and I wouldn't be surprised if it goes much higher in some common applications. With 10 iterations, I mean the amount of "layout phases" that are chained by a `requestNextPulse` during the previous layout phase. Once there is a layout phase without a `requestNextPulse`, I consider the rendering "stable".

This will have a few other major impacts that are hard to predict:
1. what about CSS passes? repeat those too? (probably yes -> really expensive)
2. the flow of apps will be completely different. As long as a pulse is running, no Runnables scheduled via Platform.runLater() can be executed. If you do 10 layout passes inside a pulse, the time between the Runnables being executed becomes an order of magnitude more than before, and that will have a major impact for some applications.

I fear that approach is going to be even more disruptive for existing applications.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457570782

From angorya at openjdk.org  Tue Oct 28 17:22:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 17:22:11 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

Interesting, thanks!  I was thinking more of 2-3 cycles, actually.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457608100

From jvos at openjdk.org  Tue Oct 28 17:15:41 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 28 Oct 2025 17:15:41 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
Message-ID: 

On Tue, 28 Oct 2025 16:51:35 GMT, John Hendrikx  wrote:

> It's not a bad idea to just run layout again if after running layout the root is still dirty.

There must be historical reasons why this is not the case. @kevinrushforth might have more background info. I would guess that the original design goal was to keep a pulse as short as possible, and the `requestNextPulse` inside a pulse would be useless with this approach. I think the `requestNextPulse` was created for this reason: don't stop the world for too long, render what we have, and try to render again as soon as possible (in the next pulse). This prevents the pulse runnable from lock the JavaFX Application Thread for too long -- as said above, there are other users for this Thread.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457583501

From kcr at openjdk.org  Tue Oct 28 17:51:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Oct 2025 17:51:48 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
 
Message-ID: <0fu4YII-LEjwhRNWr_rAVJKyx0Z7jU8xWlAUIY_cbrg=.be185a12-fd12-49eb-ae4c-f01ddf8c1f4b@github.com>

On Tue, 28 Oct 2025 17:12:50 GMT, Johan Vos  wrote:

> > It's not a bad idea to just run layout again if after running layout the root is still dirty.
> 
> There must be historical reasons why this is not the case. @kevinrushforth might have more background info. I would guess that the original design goal was to keep a pulse as short as possible, and the `requestNextPulse` inside a pulse would be useless with this approach. I think the `requestNextPulse` was created for this reason: don't stop the world for too long, render what we have, and try to render again as soon as possible (in the next pulse). This prevents the pulse runnable from lock the JavaFX Application Thread for too long -- as said above, there are other users for this Thread.

>From what I can remember, that was indeed the main reason.  Most of the layout stabilizes pretty quickly (1-3 passes), but as Johan points out, there can be cases where ~ 10 are needed. It is better for responsiveness to do run event handlers, app Runnables (via runLater), and allow animation to proceed after each layout + CSS pass than iterate until stable.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3457742036

From nlisker at gmail.com  Tue Oct 28 20:30:21 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 28 Oct 2025 22:30:21 +0200
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: <6daf355b-0b94-442f-8e1a-bc52a51283e3@gmail.com>
References: 
 
 <6daf355b-0b94-442f-8e1a-bc52a51283e3@gmail.com>
Message-ID: 

>
> You're right, I forgot about the existence of the Bindings class, and the
> helpers it has added for these cases.  I barely use it since the addition
> of fluent bindings.  That version is a lot more compact and a bit more
> workable.


The primary reason for that is that ReactFX had to introduce new property
> classes which are limited in how well they can interop with existing JavaFX
> code.  With the fluent bindings additions the need for ReactFX is limited.
> That is not to say ReactFX doesn't offer anything interesting anymore :)


I don't use Bindings a lot since fluent bindings and have basically dropped
ReactFX since then too. ReacrFX goes very far and has a lot of options,
most of them cover rare cases. It's still very good to have a ready
implementation for all that.

Static imports are not really a plus for any argument in my view :)
> Compare AssertJ and Hamcrest to see what I mean.


I very rarely use them outside of test code, but when a class does
extensive work in the context of a service class (like Bindings and
Collectors) I could see using them. Also, I use Google Truth (nothing
against AssertJ) :) Interestingly, JavaFX has a dependency on Hamcrest.

It is an extension on the fluent API, it doesn't introduce anything that
> isn't possible currently, just like `map` and `flatMap` didn't introduce
> anything new, nor did `subscribe`.  It is intended to be a more
> discoverable, fluent and modern API, and to fill a gap where one has to go
> from the fluent binding model to a static helper class model as soon as you
> go from mapping just one source to needing two or more sources.


 The 'select` methods on Bindings were not compile-time safe and IIRC used
reflection. I never used them. Subscribe made memory management easier and
avoided sneaky memory leaks (which can still happen, just less often).
There were very good reasons to include them. Here it's more a matter of
ergonomics.

On Tue, Oct 28, 2025 at 10:28?AM John Hendrikx 
wrote:

> Thanks for taking a look Nir, I really appreciate it :)
> On 26/10/2025 13:56, Nir Lisker wrote:
>
> When I need to combine observable values I usually do something like:
>
> Bindings.createDoubleBinding(() ->  width.get() / height.get(), height,
> width);
>
> which is much less cumbersome than subclassing (although a bit less
> performant I think). It works for an arbitrary number of observables
> (including) observable lists/sets/maps too:
>
> You're right, I forgot about the existence of the Bindings class, and the
> helpers it has added for these cases.  I barely use it since the addition
> of fluent bindings.  That version is a lot more compact and a bit more
> workable.
>
>
> Bindings.createDoubleBinding(() ->  list.getFirst() / height.get() *
> map.get("A"), height, list, map); // assume this makes sense somehow
>
> ReactFX, which is the go-to library for such extension, has a 'combine'
> method that work like this:
>
> Val.combine(height, width, (h, w) -> w / h);
>
> I'm aware of this, and it is something to be considered as an addition.
> It is similar to the argument where there is a `Subscription.combine` and
> `subscription.and`, one being static and the other being a fluent method.
> I think however we shouldn't be relying on ReactFX too much anymore these
> days (I haven't used it in years now).  The primary reason for that is that
> ReactFX had to introduce new property classes which are limited in how well
> they can interop with existing JavaFX code.  With the fluent bindings
> additions the need for ReactFX is limited.  That is not to say ReactFX
> doesn't offer anything interesting anymore :)
>
> To assess the proposal, I tried to write your JEP examples with the
> current JavaFX.
>
> Multi-stage chain (not sure how you mapped to a Point3D from a Point2D and
> a number):
>
> ObjectBinding point2d = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y);
> ObjectBinding point3d = Bindings.createObjectBinding(() -> new
> Point3D(point2d.get().getX(), point2d.get().getY(), z.get()), point2d, z);
>
> Combining chains:
>
>
> ObjectBinding point1 = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y);
>
> ObjectBinding point2 = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y);
> ObjectBinding line = Bindings.createObjectBinding(() -> new
> Line2D(point1, point2), point1, point2); // Line2D is not a JavaFX class
>
> Using a default value:
>
> ObservableValue point1 = Bindings.createObjectBinding(() -> new
> Point2D(x.get(), y.get()), x, y).orElse(Point2D.ZERO);
>
>
> Some observations:
> Bindings returns a Binding rather than an ObservableValue and also has
> primitive specialization versions that have their unique methods (add,
> subtract...). These methods, however, can be replicated with fluent
> bindings and they also have the "known" subtle GC issue for the
> intermediary values.
>
> Yes, I don't think we should cater to primitive specializations. Bindings
> tend to be high level enough (often eventually tied to a UI) that it makes
> little sense to "optimize" these at the cost of 8x more variants. The GC
> issues are often insidious, and my problems in that area have largely
> disappeared with the addition of the fluent bindings and subscribe API's.
> This is why I'm hesitant to use API's from the Bindings class, and why I
> think FX should offer alternatives in that area.
>
> Also, static imports can make these calls less ceremonious:
> createObjectBinding(() -> new Point2D(x.get(), y.get()), x, y);
>
> Static imports are not really a plus for any argument in my view :)
> Compare AssertJ and Hamcrest to see what I mean.
>
>
> The proposal is more ergonomic with its fluency for a couple of values,
> but I'm not sure it solves enough problems that the current mechanism can't.
>
> It is an extension on the fluent API, it doesn't introduce anything that
> isn't possible currently, just like `map` and `flatMap` didn't introduce
> anything new, nor did `subscribe`.  It is intended to be a more
> discoverable, fluent and modern API, and to fill a gap where one has to go
> from the fluent binding model to a static helper class model as soon as you
> go from mapping just one source to needing two or more sources.
>
> --John
>
>
> On Sun, Oct 26, 2025 at 11:59?AM John Hendrikx 
> wrote:
>
>> JEP: https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a
>>
>> Hi everyone,
>>
>> I'd like to propose an extension to the fluent bindings API on
>> ObservableValue (map, flatMap, orElse) which were introduced in JavaFX
>> 19 over 3 years ago.
>>
>> The API currently is very powerful when dealing with a single
>> observable, but lacks support when dealing with multiple observables.
>> For example, let's say you want to compute a width/height ratio.  You
>> could write this:
>>
>>     ObservableValue ratio = width.map(w -> w / height.get());
>>
>> ... but you'll quickly find that such an observable will not update
>> itself when height changes, only when width changes.
>>
>> The go-to solution for this is currently:
>>
>>     DoubleBinding ratio = new DoubleBinding() {
>>         { bind(width, height); }
>>
>>         protected double computeValue() { return width.get() /
>> height.get(); }
>>     }
>>
>> My proposal would extend ObservableValue with a new `with` method that
>> returns an intermediate stage that can be easily converted back to an
>> ObservableValue:
>>
>>     ObservableValue ratio = width.with(height).map((w, h) -> w /
>> h);  // yields a ratio that updates whenever w or h changes
>>
>> Or for example:
>>
>>      ObservableValue point = x.with(y).map(Point::new);  //
>> yields a Point that updates whenever x or y changes
>>
>> The intermediate stage would not be an observable value itself.  This
>> limits the API surface, and makes this proposal fairly lightweight and
>> much easier to implement.
>>
>> Please see the JEP for the full proposal.  I look forward to your
>> feedback!
>>
>> --John
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Tue Oct 28 21:36:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 21:36:17 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:54:13 GMT, Lukasz Kostyra  wrote:

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

code review only - I did not test it.

modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java line 91:

> 89:     public void update(MediaFrame frame, boolean skipFlush)
> 90:     {
> 91:         if (!resource.isValid()) {

related - D3DTextureResource line 40 is 


    public void free() {
        if (resource != null) {
            resource.dispose();
        }
    }


should there be `resource = null;` after `resource.dispose()` ?

modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java line 93:

> 91:         if (!resource.isValid()) {
> 92:             return;
> 93:         }

are these the only two places where we need the check?

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3390861433
PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2471094140
PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2471089531

From kcr at openjdk.org  Tue Oct 28 21:42:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Oct 2025 21:42:47 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext
In-Reply-To: 
References: 
Message-ID: 

On Tue, 28 Oct 2025 15:54:13 GMT, Lukasz Kostyra  wrote:

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

This looks similar to the case in [JDK-8368631](https://bugs.openjdk.org/browse/JDK-8368631) solved by PR #1919.

@arapte can you take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3458608333

From angorya at openjdk.org  Tue Oct 28 22:28:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 28 Oct 2025 22:28:00 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

tested on macOS 15.7.1 M1
the reproducer works
found no ill effects in the monkey tester.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1870#pullrequestreview-3391055606

From kcr at openjdk.org  Tue Oct 28 22:35:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Oct 2025 22:35:26 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v2]
In-Reply-To: <8RiPJ6U7I7MzDpYG3gqC123-U99ahQd398hTDKw8dqo=.49ad9845-f231-408a-a2d4-a3a28a6793ea@github.com>
References: 
 <8RiPJ6U7I7MzDpYG3gqC123-U99ahQd398hTDKw8dqo=.49ad9845-f231-408a-a2d4-a3a28a6793ea@github.com>
Message-ID: 

On Wed, 22 Oct 2025 23:19:40 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo redo enabled logic

The API changes look good. I left a couple comments on the API docs.

Now that undoRedo is state, you should add tests for the set operations, checking default state and setting it to both false and true on the control both with / without model. I also recommend adding tests of its operation when calling undo / redo with the attr set to both false and true.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 439:

> 437: 
> 438:     /**
> 439:      * Replaces text in this CodeArea.  This method creates an undo/redo entry.

It creates an undo/redo entry if the undoRedo attribute is `true`.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1865:

> 1863: 
> 1864:     /**
> 1865:      * Replaces the specified range with the new input.  This method creates an undo entry.

It creates an undo/redo entry if the undoRedo attribute is `true`.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 624:

> 622:      * @param end end text position
> 623:      * @param text text string to insert
> 624:      * @param allowUndo when true, creates an undo-redo entry

Do you need to note that this method creates an undo/redo entry (if the undoRedo attribute is true)?

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 656:

> 654:      * 

> 655:      * After the model applies the requested changes, an event is sent to all the registered listeners.
> 656:      * This method creates an undo/redo entry.

It creates an undo/redo entry if the undoRedo attribute is true.

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3391009394
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2471187922
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2471200486
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2471208075
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2471208416

From jhendrikx at openjdk.org  Tue Oct 28 22:36:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Oct 2025 22:36:23 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 17:09:38 GMT, Johan Vos  wrote:

> > How many pulses are needed to finish the layout? If we ignore for a second some pathological cases when the layout process never ends causing continuous flicker, is there a safe upper limit?
> 
> Realistically, I'd say 10 iterations is pretty common, and I wouldn't be surprised if it goes much higher in some common applications. With 10 iterations, I mean the amount of "layout phases" that are chained by a `requestNextPulse` during the previous layout phase. Once there is a layout phase without a `requestNextPulse`, I consider the rendering "stable".

In what software do you get 10 iterations as "common"?  That's close to 200 ms @ 60 fps.  The software would look and perform worse than decades old software.  I'm running quite complex software with FX, and never does a layout take more than 1 pass (not counting the superfluous pass made by FX currently) as that would be absolutely unacceptable for my work that must look absolutely smooth and polished.
 
> This will have a few other major impacts that are hard to predict:
> 
> 1. what about CSS passes? repeat those too? (probably yes -> really expensive)

Ehr, no definitely not.  Just like you shouldn't be modifying layout positions during layout, you should not be doing things (during layout) that modify CSS styles because the CSS pass has already completed.  Modifying CSS during layout (which changes anything size or position related) is a guaranteed jump of your UI as a next pass is required.  This looks flakey and unprofessional.

For example, you also should not be modifying the scene graph during layout, because if you say add a new child (like a list cell or something) that cell will be rendered **without** styles, resulting in things like white flashes on your black background because that's the default background.  This kind of stuff must be done in a `Scene::addPreLayoutListener` if you want to ensure your application looks smooth.

> 2. the flow of apps will be completely different. As long as a pulse is running, no Runnables scheduled via Platform.runLater() can be executed. If you do 10 layout passes inside a pulse, the time between the Runnables being executed becomes an order of magnitude more than before, and that will have a major impact for some applications.

Nobody is suggesting running layout passes until the UI settles.

Anyway, the only practical use would be to cover up self created layout problems, and encourage more bad behavior, so perhaps it is better to not even consider this.

You mentioned that FX "promises to handle all edge cases".  Do you care to show me where it does so?  Because FX would be the first system with complex layouts that would be doing so.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3458829150

From kcr at openjdk.org  Tue Oct 28 22:56:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Oct 2025 22:56:18 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 19:04:16 GMT, Andy Goryachev  wrote:

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

Reviewer: @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3458873932

From jhendrikx at openjdk.org  Tue Oct 28 23:14:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 28 Oct 2025 23:14:22 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: <11zeIm7vBa0XUqZohlVZWDBxYsHLIfr4IkAIlxKzqMY=.b8b31296-d6ff-4611-95c2-e31f9d6a9129@github.com>
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
 <11zeIm7vBa0XUqZohlVZWDBxYsHLIfr4IkAIlxKzqMY=.b8b31296-d6ff-4611-95c2-e31f9d6a9129@github.com>
Message-ID: 

On Tue, 28 Oct 2025 17:00:05 GMT, Andy Goryachev  wrote:

> > Also, the CPU cost is still there
> 
> that's true, but the cost will be there anyway - but now we are skipping the rendering and removing the flicker. So it's a win-win, as long as the layout converges.

If nothing else happens in the scene, then it would also save a rendering pass yes.

> One example is when the layout must further change based on the current layout pass, such as when the scroll bar appears or disappears.

That should not be the case because of how the layout pass is split into the `compute` calls and the `layoutChildren` calls.

The scene or any layout root needs to know what size things will be, and so will use the `prefWidth` (etc) calls (that delegate to the `compute` calls) before doing any `layoutChildren` call.  These calls cascade down as deep as necessary through-out most of the scene graph (even parts not needing layout), and this would be expensive if they weren't also aggressively cached.

The `compute` calls don't need to be a `one call = one result` deal.  Often additional calls are done for more complex layouts (like for biased controls where the opposite `compute` call is done first so the related size can be passed to the wanted `compute` axis).  And this can also happen for `ScrollPane` which can look at the result of a `compute` call then decide it needs a scroll bar, redo the computation of how much space is available for the content (which may cause the other scroll bar to also be needed).  It can then position its children correctly in one pass.

See `ScrollPaneSkin#layoutChildren` code where you can see it do several checks in a row to determine the correct size when scrollbars must appear, all in one pass :)

Also of note is that it always creates and adds the scroll bars, and just keeps them invisible until needed, as creating them on demand would be too late and cause flicker (unless you do this in a prelayout listener).

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3458912490

From john.hendrikx at gmail.com  Tue Oct 28 23:32:10 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 29 Oct 2025 00:32:10 +0100
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
 
 <6daf355b-0b94-442f-8e1a-bc52a51283e3@gmail.com>
 
Message-ID: 


>
>     It is an extension on the fluent API, it doesn't introduce
>     anything that isn't possible currently, just like `map` and
>     `flatMap` didn't introduce anything new, nor did `subscribe`.? It
>     is intended to be a more discoverable, fluent and modern API, and
>     to fill a gap where one has to go from the fluent binding model to
>     a static helper class model as soon as you go from mapping just
>     one source to needing two or more sources.
>
>
> ?The 'select` methods on Bindings were not compile-time safe and IIRC
> used reflection. I never used them. Subscribe made memory management
> easier and avoided sneaky memory leaks (which can still happen, just
> less often). There were very good reasons to include them. Here it's
> more a matter of ergonomics.

True, perhaps that isn't enough to justify them.? They do allow some
other interesting things perhaps later that may be useful.

First, you could subscribe on a combination of properties:

?????? x.with(y).map(Point::new).subscribe(p ->? ... get points here ... );

To make this easy to use, we'd want to make `map` null safe, like `map`
in `ObservableValue`, and you'll just have to use `orElse` to deal with
`null`s (or perhaps a `mapNull` variant I've seen in some stream type
frameworks).

Then I realized there could be another potentially cool use here for the
`null` skipping behavior (but I'll admit it is a bit far fetched, but
perhaps it will lead to other ideas).? What if I did this:

?????? // initially (x, y) are (0, 10):
?????? x.with(y).map(Point::new).subscribe(System.out::println);
?????? x.set(null);
?????? y.set(null);
?????? x.set(10);
?????? y.set(0);

Because how `map` would skip nulls, this would only print?Point(0, 10)
and Point(10, 0) ...

As said, it is far fetched, and clumsy to do, but I've thinking for a
long time about adding some sort of transactional?logic?for properties
as well (and I do have some other solutions for that already that I've
been playing with) and this kind of mini-transaction sort of popped up
out of nowhere.

--John

>
> On Tue, Oct 28, 2025 at 10:28?AM John Hendrikx
>  wrote:
>
>     Thanks for taking a look Nir, I really appreciate it :)
>
>     On 26/10/2025 13:56, Nir Lisker wrote:
>>     When I need to combine observable values I usually do something like:
>>
>>     Bindings.createDoubleBinding(() ->? width.get() / height.get(),
>>     height, width);
>>
>>     which is much less cumbersome than subclassing (although a bit
>>     less performant I think). It works for an arbitrary number of
>>     observables (including) observable lists/sets/maps too:
>
>     You're right, I forgot about the existence of the Bindings class,
>     and the helpers it has added for these cases.? I barely use it
>     since the addition of fluent bindings.? That version is a lot more
>     compact and a bit more workable.
>
>>
>>     Bindings.createDoubleBinding(() ->? list.getFirst() /
>>     height.get() * map.get("A"), height, list, map); // assume this
>>     makes sense somehow
>>
>>     ReactFX, which is the go-to library for such extension, has a
>>     'combine' method that work like this:
>>
>>     Val.combine(height, width, (h, w) -> w / h);
>
>     I'm aware of this, and it is something to be considered as an
>     addition.? It is similar to the argument where there is a
>     `Subscription.combine` and `subscription.and`, one being static
>     and the other being a fluent method.? I think however we shouldn't
>     be relying on ReactFX too much anymore these days (I haven't used
>     it in years now).? The primary reason for that is that ReactFX had
>     to introduce new property classes which are limited in how well
>     they can interop with existing JavaFX code.? With the fluent
>     bindings additions the need for ReactFX is limited.? That is not
>     to say ReactFX doesn't offer anything interesting anymore :)
>
>>     To assess the proposal, I tried to write your JEP examples with
>>     the current JavaFX.
>>
>>     Multi-stage chain (not sure how you mapped to a Point3D from a
>>     Point2D and a number):
>>
>>     ObjectBinding point2d = Bindings.createObjectBinding(()
>>     -> new Point2D(x.get(), y.get()), x, y);
>>     ObjectBinding point3d = Bindings.createObjectBinding(()
>>     -> new Point3D(point2d.get().getX(), point2d.get().getY(),
>>     z.get()), point2d, z);
>>
>>     Combining chains:
>>
>>
>>     ObjectBinding point1 = Bindings.createObjectBinding(()
>>     -> new Point2D(x.get(), y.get()), x, y);
>>
>>     ObjectBinding point2 = Bindings.createObjectBinding(()
>>     -> new Point2D(x.get(), y.get()), x, y);
>>     ObjectBinding line = Bindings.createObjectBinding(() ->
>>     new Line2D(point1, point2), point1, point2); // Line2D is not a
>>     JavaFX class
>>
>>
>>     Using a default value:
>>
>>     ObservableValue point1 = Bindings.createObjectBinding(()
>>     -> new Point2D(x.get(), y.get()), x, y).orElse(Point2D.ZERO);
>>
>>
>>     Some observations:
>>     Bindings returns a Binding rather than an ObservableValue and
>>     also has primitive specialization versions that have their unique
>>     methods (add, subtract...). These methods, however, can be
>>     replicated with fluent bindings and they also have the "known"
>>     subtle GC issue for the intermediary values.
>     Yes, I don't think we should cater to primitive specializations.
>     Bindings tend to be high level enough (often eventually tied to a
>     UI) that it makes little sense to "optimize" these at the cost of
>     8x more variants. The GC issues are often insidious, and my
>     problems in that area have largely disappeared with the addition
>     of the fluent bindings and subscribe API's.? This is why I'm
>     hesitant to use API's from the Bindings class, and why I think FX
>     should offer alternatives in that area.
>>     Also, static imports can make these calls less ceremonious:
>>     createObjectBinding(() -> new Point2D(x.get(), y.get()), x, y);
>     Static imports are not really a plus for any argument in my view
>     :)? Compare AssertJ and Hamcrest to see what I mean.
>>
>>     The proposal is more ergonomic with?its?fluency for a couple of
>>     values, but I'm not sure it solves enough problems that the
>>     current mechanism can't.
>
>     It is an extension on the fluent API, it doesn't introduce
>     anything that isn't possible currently, just like `map` and
>     `flatMap` didn't introduce anything new, nor did `subscribe`.? It
>     is intended to be a more discoverable, fluent and modern API, and
>     to fill a gap where one has to go from the fluent binding model to
>     a static helper class model as soon as you go from mapping just
>     one source to needing two or more sources.
>
>     --John
>
>>
>>     On Sun, Oct 26, 2025 at 11:59?AM John Hendrikx
>>      wrote:
>>
>>         JEP:
>>         https://gist.github.com/hjohn/611acb65769b68a845b8919c62a3e99a
>>
>>         Hi everyone,
>>
>>         I'd like to propose an extension to the fluent bindings API on
>>         ObservableValue (map, flatMap, orElse) which were introduced
>>         in JavaFX
>>         19 over 3 years ago.
>>
>>         The API currently is very powerful when dealing with a single
>>         observable, but lacks support?when dealing with multiple
>>         observables.?
>>         For example, let's say you want to compute a width/height
>>         ratio.? You
>>         could write this:
>>
>>         ??? ObservableValue ratio = width.map(w -> w /
>>         height.get());
>>
>>         ... but you'll quickly find that such an observable will not
>>         update
>>         itself when height changes, only when width changes.
>>
>>         The go-to solution for this is currently:
>>
>>         ??? DoubleBinding ratio = new DoubleBinding() {
>>         ??????? { bind(width, height); }
>>
>>         ??????? protected double computeValue() { return width.get() /
>>         height.get(); }
>>         ??? }
>>
>>         My proposal would extend ObservableValue with a new `with`
>>         method that
>>         returns an intermediate stage that can be easily?converted
>>         back to an
>>         ObservableValue:
>>
>>         ??? ObservableValue ratio =
>>         width.with(height).map((w, h) -> w /
>>         h);? // yields a ratio that updates whenever w or h changes
>>
>>         Or for example:
>>
>>         ???? ObservableValue point =
>>         x.with(y).map(Point::new);? //
>>         yields a Point that updates whenever x or y changes
>>
>>         The intermediate stage would not be an observable value
>>         itself.? This
>>         limits the API surface, and makes this proposal fairly
>>         lightweight and
>>         much easier to implement.
>>
>>         Please see the JEP for the full proposal.? I look forward to
>>         your feedback!
>>
>>         --John
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jbhaskar at openjdk.org  Wed Oct 29 03:25:47 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 29 Oct 2025 03:25:47 GMT
Subject: RFR: 8370235: WebKit build fails on Windows 32-bit and Linux 32-bit
 after JDK-8367578
Message-ID: 

Issue: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578
Solution: [JSC] Use llintOpWithReturn for instanceof on 32-bits
https://github.com/WebKit/WebKit/commit/05f6e3818e1be6d1186ebfd5e059f669361edf0a

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

Commit messages:
 - 8370235: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578

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

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

From arapte at openjdk.org  Wed Oct 29 07:37:22 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 29 Oct 2025 07:37:22 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext
In-Reply-To: 
References: 
Message-ID: <6PoLkE34IJiTwSYjrKGWZ_jiG7okXolMTfZcDPsNf08=.6e179441-470f-45d9-b8e1-ca0a237eaccf@github.com>

On Tue, 28 Oct 2025 15:54:13 GMT, Lukasz Kostyra  wrote:

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

Looks safe and the issue gets resolved.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3392011719

From duke at openjdk.org  Wed Oct 29 10:35:48 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Wed, 29 Oct 2025 10:35:48 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 24 Oct 2025 01:40:59 GMT, Cormac Redmond  wrote:

> Hi. Another bug, a slightly more serious one this time.
> 
> Dialogs cannot be re-used. E.g., sequentially calling showAndWait() twice on the same instance, does not work:
> ...
> ```

Hi @mstr2: any thoughts on this one (in particular)? Seems like a bug...

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3460811167

From lkostyra at openjdk.org  Wed Oct 29 11:09:11 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 29 Oct 2025 11:09:11 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 21:28:54 GMT, Andy Goryachev  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java line 91:
> 
>> 89:     public void update(MediaFrame frame, boolean skipFlush)
>> 90:     {
>> 91:         if (!resource.isValid()) {
> 
> related - D3DTextureResource line 40 is 
> 
> 
>     public void free() {
>         if (resource != null) {
>             resource.dispose();
>         }
>     }
> 
> 
> should there be `resource = null;` after `resource.dispose()` ?

It could add another layer of safety and make any potential future NPEs more easy to track - I'll add this.

> modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java line 93:
> 
>> 91:         if (!resource.isValid()) {
>> 92:             return;
>> 93:         }
> 
> are these the only two places where we need the check?

Yes, as far as I know other Prism-backend-specific resources already do similar checks, either Java side or Native side.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2472580324
PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2472576368

From lkostyra at openjdk.org  Wed Oct 29 11:21:31 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 29 Oct 2025 11:21:31 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  D3DTextureResource: Set resource to null after disposing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1951/files
  - new: https://git.openjdk.org/jfx/pull/1951/files/662f03dd..f7c452e0

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

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

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

From kcr at openjdk.org  Wed Oct 29 12:33:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 12:33:54 GMT
Subject: RFR: 8370235: WebKit build fails on Windows 32-bit and Linux
 32-bit after JDK-8367578
In-Reply-To: 
References: 
Message-ID: <135toSYqE6MCUbx29HvgXRJHoOK4WgGMXZP3i81j21w=.a864cfef-233e-4415-b34e-8536fd7f508e@github.com>

On Wed, 29 Oct 2025 03:19:41 GMT, Jay Bhaskar  wrote:

> Issue: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578
> Solution: [JSC] Use llintOpWithReturn for instanceof on 32-bits
> https://github.com/WebKit/WebKit/commit/05f6e3818e1be6d1186ebfd5e059f669361edf0a

LGTM. The patch matches the upstream commit.

Reviewers: @kevinrushforth @HimaBinduMeda

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1952#pullrequestreview-3393087042
PR Comment: https://git.openjdk.org/jfx/pull/1952#issuecomment-3461266278

From kcr at openjdk.org  Wed Oct 29 12:36:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 12:36:58 GMT
Subject: RFR: 8364777: RichTextArea: cursor over scrollbar
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Oct 2025 20:12:34 GMT, Andy Goryachev  wrote:

> Fixes the cursor over the content area vs other parts of the `RichTextArea` and `CodeArea`.
> 
> Root cause: styling wrong thing in modena.css.

LGTM

One reviewer is sufficient for this simple fix.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1947#pullrequestreview-3393105528

From kcr at openjdk.org  Wed Oct 29 13:58:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 13:58:54 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

It works as expected on macOS (I'll try it on Windows later). I left a few comments, mostly about the line separator as it relates to the private `getText(...)` method in RichTextArea.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/RichTextAreaHelper.java line 58:

> 56:     }
> 57: 
> 58:     public static boolean getText(RichTextArea t, TextPos start, TextPos end, StringBuilder sb, int limit, String lineSeparator) {

Is the lineSeparator parameter really needed here? If not, I recommend removing it.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 264:

> 262:             dy = f.snappedTopInset();
> 263: 
> 264:             p = f.rangeShape(start, end); // TODO new api, no null

Is this "TODO" really related to IME? If not, I recommend removing it.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1438:

> 1436:      * @param sb the buffer to copy to
> 1437:      * @param limit the maximum number of characters to copy, must be >= 0
> 1438:      * @param lineSeparator the newline separator sequence, or null to use the platform default

Whether and how to add lineSeparator is under review via PR #1944. I recommend removing everything related to line separators for this PR, unless you want this PR to be dependent on #1944.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1442:

> 1440:      * @since 26
> 1441:      */
> 1442:     // TODO depends on JDK-8370140 (line separator property), private for now

While a `getText(...)` method would be useful, I don't see an enhancement request that proposes it. I would make it more clear that this is not public API. If you want to leave the docs in place for a future enhancement that might provide such a public API, I recommend changing `@since 26` to `@since 99` (or similar).

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1469:

> 1467:                 beg = start.offset();
> 1468:             } else {
> 1469:                 sb.append(lineSeparator);

For now, should `lineSeparator` be hardcoded as `"\n"` or should it be the `line.separator` property? We often use `\n` regardless of which platform we are on unless we are writing to a file or doing something else where it matters. This is more a question for PR #1944, so whatever you do here will very likely be modified when that enhancement is implemented. Unless you want to make this PR dependent on that one, choose something now (other than passing it in as a method parameter, since that seems an unlikely choice) and add a comment that it will need to be revisited.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/skin/RichTextAreaSkin.java line 597:

> 595: 
> 596:     // while IME is active
> 597:     static class Ime {

I think can be private.

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

PR Review: https://git.openjdk.org/jfx/pull/1938#pullrequestreview-3393143461
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2472872756
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2472883166
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2472916772
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2473111435
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2473179810
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2473056656

From arapte at openjdk.org  Wed Oct 29 14:05:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 29 Oct 2025 14:05:00 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
Message-ID: 

Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

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

Commit messages:
 - boot jdk update to 25.0.1
 - gradle update to 910

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

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

From arapte at openjdk.org  Wed Oct 29 14:13:45 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 29 Oct 2025 14:13:45 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: <0OJBf2RGJNyCziV_t_JRVs3D8l7Vef4G7kgT4AhW4OI=.42fb7a52-0cb4-498b-b0f5-bb6670adfa43@github.com>

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

@kevinrushforth Please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3461755914

From angorya at openjdk.org  Wed Oct 29 14:26:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 14:26:34 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 11:21:31 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   D3DTextureResource: Set resource to null after disposing

thanks for making the change!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3393834194

From angorya at openjdk.org  Wed Oct 29 14:31:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 14:31:09 GMT
Subject: Integrated: 8364777: RichTextArea: cursor over scrollbar
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Oct 2025 20:12:34 GMT, Andy Goryachev  wrote:

> Fixes the cursor over the content area vs other parts of the `RichTextArea` and `CodeArea`.
> 
> Root cause: styling wrong thing in modena.css.

This pull request has now been integrated.

Changeset: 200b01fd
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/200b01fd58cd78fd0519ddd8b7694a7c96606401
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8364777: RichTextArea: cursor over scrollbar

Reviewed-by: kcr

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

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

From lkostyra at openjdk.org  Wed Oct 29 15:03:58 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 29 Oct 2025 15:03:58 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text
In-Reply-To: 
References: 
Message-ID: 

On Mon, 27 Oct 2025 19:04:16 GMT, Andy Goryachev  wrote:

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

The added test works fine, but I'm having some issues with getting this to work in RTA Demo.

I started RichEditorDemo from `apps/samples/RichTextAreaDemo` and this is the result I get when trying to add text at the end of bolded "testing" word:

Image

To be precise, the steps are:
1. Write "testing testing testing"
2. Mark the middle "testing" and use Ctrl+B to bold it
3. Click at the end of bolded "testing" word and start typing

I figured the "aaaaaaa" should be bolded, but it isn't. Is this the expected result?

What is even more interesting, is that I cannot un-bold the middle word after it became bolded. Hard to say why but it doesn't happen on master. I also noticed the "B" bolding button in the UI does not highlight when you put the cursor in the middle of bolded text, which also works on master.

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

PR Review: https://git.openjdk.org/jfx/pull/1950#pullrequestreview-3394101023

From kcr at openjdk.org  Wed Oct 29 15:13:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 15:13:08 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3462128800

From kcr at openjdk.org  Wed Oct 29 15:31:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 15:31:18 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3394309637

From kizune at openjdk.org  Wed Oct 29 15:36:35 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Oct 2025 15:36:35 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

Looks good.

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

Marked as reviewed by kizune (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3394347238

From jhendrikx at openjdk.org  Wed Oct 29 16:11:42 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Oct 2025 16:11:42 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 11:21:31 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   D3DTextureResource: Set resource to null after disposing

I'm running into this problem frequently with an image heavy application.  Will this address the cause of the issue, or just the symptoms?

I've been monitoring the resource usage, and when this bug occurs it usually is because it is trying to free resources, but is unable to free sufficient resources to allocate a new resource.  Now that the NPE is fixed, what happens then with the original problem of being unable to free up enough space for a new resource?

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3462495532

From kizune at openjdk.org  Wed Oct 29 16:17:49 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Oct 2025 16:17:49 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

I really want to test it on Linux - the IME there is quite fragile - and i will get back once i get my Linux box updated and running again. Should be done by the end of the week.

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3462521988

From kcr at openjdk.org  Wed Oct 29 16:20:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 16:20:44 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: <0OJBf2RGJNyCziV_t_JRVs3D8l7Vef4G7kgT4AhW4OI=.42fb7a52-0cb4-498b-b0f5-bb6670adfa43@github.com>
References: 
 <0OJBf2RGJNyCziV_t_JRVs3D8l7Vef4G7kgT4AhW4OI=.42fb7a52-0cb4-498b-b0f5-bb6670adfa43@github.com>
Message-ID: 

On Wed, 29 Oct 2025 14:11:02 GMT, Ambarish Rapte  wrote:

>> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
>> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)
>
> @kevinrushforth Please take a look.

@arapte Please wait for @tiainen or @johanvos to verify that it works in their build environment.

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3462534522

From hmeda at openjdk.org  Wed Oct 29 16:52:25 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 29 Oct 2025 16:52:25 GMT
Subject: RFR: 8370235: WebKit build fails on Windows 32-bit and Linux
 32-bit after JDK-8367578
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 03:19:41 GMT, Jay Bhaskar  wrote:

> Issue: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578
> Solution: [JSC] Use llintOpWithReturn for instanceof on 32-bits
> https://github.com/WebKit/WebKit/commit/05f6e3818e1be6d1186ebfd5e059f669361edf0a

LGTM. No issue seen.

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

Marked as reviewed by hmeda (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1952#pullrequestreview-3394825041

From sykora at openjdk.org  Wed Oct 29 16:57:20 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 29 Oct 2025 16:57:20 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
 <0OJBf2RGJNyCziV_t_JRVs3D8l7Vef4G7kgT4AhW4OI=.42fb7a52-0cb4-498b-b0f5-bb6670adfa43@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 16:17:35 GMT, Kevin Rushforth  wrote:

>> @kevinrushforth Please take a look.
>
> @arapte Please wait for @tiainen or @johanvos to verify that it works in their build environment.

@kevinrushforth I'll start a verification run.

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3462679360

From kcr at openjdk.org  Wed Oct 29 17:01:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:01:14 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 23 Oct 2025 17:28:31 GMT, Andy Goryachev  wrote:

>> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
>> 
>> The impacted areas are:
>> - saving to plain text
>> - copying to plain text
>> 
>> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
>  - tests
>  - line endings

Reviewers: @kevinrushforth @jayathirthrao

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

PR Comment: https://git.openjdk.org/jfx/pull/1944#issuecomment-3462691713

From kcr at openjdk.org  Wed Oct 29 17:28:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:28:41 GMT
Subject: RFR: 8091429: ObservableList#setAll(int from, int to,
 Collection col) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 20 Oct 2025 05:06:20 GMT, John Hendrikx  wrote:

>> This PR implements two new default methods on `ObservableList` to be able to replace elements at a given position or within a specified range.
>> 
>> Justification for this change is to allow an `ObservableList` to be bulk modified resulting in a single `ListChangeListener` call back.  In this way the callbacks don't observe the list changing its size from S to S-X back to S again(*). Currently the only way to bulk replace a range of items is to remove X items then add X items, resulting in two listener callbacks in between which the size of the list can be observed to change.
>> 
>> The other alternative is to call `set` individually for each item, which results in many change notifications.
>> 
>> With the addition of this PR, and the changes in `ModifiableObservableListBase`, replacing a range of items becomes a single change callback.
>> 
>> (*) The list may indeed change size still as plain `List` does not have `setAll` operations; size listeners may observe this, but it will no longer be observable from a `ListChangeListener` due to multiple separate callbacks.
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix test
>  - Rename setAll to replaceRange and removed superfluous method

I can review this.

@hjohn If you're happy with the current `replaceRange` name (which seems good to me), can you update the JBS and PR title to reflect this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3462788655

From kcr at openjdk.org  Wed Oct 29 17:32:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:32:44 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text
In-Reply-To: 
References: 
Message-ID: <84mPBrotB7dOsqIhT-V4sBNpzYVuhyuItXwnTJS9y3k=.1f81d93c-7998-4472-906a-e782b611fcd1@github.com>

On Mon, 27 Oct 2025 19:04:16 GMT, Andy Goryachev  wrote:

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

Sounds like this could use a second reviewer. @Ziad-Mid can you also review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1950#issuecomment-3462801332

From kcr at openjdk.org  Wed Oct 29 17:33:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:33:49 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 18 Sep 2025 15:47:03 GMT, Martin Fox  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.

Reviewers: @beldenfox @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3462804291

From kcr at openjdk.org  Wed Oct 29 17:40:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:40:59 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
References: 
 
 <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
Message-ID: 

On Mon, 13 Oct 2025 12:55:58 GMT, Marius Hanl  wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadoc
>
> There seems to be an intermediate test failure, maybe a race condition unrelated to this change:
> 
> 
> TaskEventTest > cancelledCalledAfterHandler() FAILED
>     org.opentest4j.AssertionFailedError: expected:  but was: 
>         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.AssertTrue.failNotTrue(AssertTrue.java:63)
>         at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
>         at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
>         at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:183)
>         at app//test.javafx.concurrent.TaskEventTest.cancelledCalledAfterHandler(TaskEventTest.java:410)

@Maran23 In case you missed it, this is pending changes from you.

1. I noted some final doc changes in [this comment above](#discussion_r2455868260).
2. I had added an [earlier comment](#issuecomment-3393245504) about adding your perf test to the PR somewhere under `tests/performance`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3462826572

From kcr at openjdk.org  Wed Oct 29 17:41:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:41:54 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 7 Oct 2025 16:10:36 GMT, Michael Strau?  wrote:

>> 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 pull request now contains 13 commits:
> 
>  - resolve merge conflicts
>  - Merge branch 'master' into feature/media-features-viewport-characteristics
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/css/CssParser_mediaQuery_Test.java
>  - 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
>  - ... and 3 more: https://git.openjdk.org/jfx/compare/e8820e24...3dabf1e0

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3462829836

From kcr at openjdk.org  Wed Oct 29 17:42:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:42:59 GMT
Subject: RFR: 8366568: Allow replacing built in application menu in system
 menu bar [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <1YTal4iyaMg9UN68AL0RlSNGrn_yWgdUl6GYXgslHCc=.5ea473ff-00a2-4ffe-a4c0-245dcdcf04c0@github.com>

On Wed, 3 Sep 2025 12:59:28 GMT, Kevin Rushforth  wrote:

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

Reviewers: @kevinrushforth @arapte

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

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

From angorya at openjdk.org  Wed Oct 29 17:50:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 17:50:59 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>
References: 
 <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>
Message-ID: 

On Wed, 29 Oct 2025 12:45:13 GMT, Kevin Rushforth  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 264:
> 
>> 262:             dy = f.snappedTopInset();
>> 263: 
>> 264:             p = f.rangeShape(start, end); // TODO new api, no null
> 
> Is this "TODO" really related to IME? If not, I recommend removing it.

this code predates [JDK-8357594](https://bugs.openjdk.org/browse/JDK-8357594)
Additional geometry-based Text/TextFlow APIs.  I am planning to migrate to the new API in a follow-up.

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

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2474391416

From kcr at openjdk.org  Wed Oct 29 17:56:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 17:56:12 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
 <0OJBf2RGJNyCziV_t_JRVs3D8l7Vef4G7kgT4AhW4OI=.42fb7a52-0cb4-498b-b0f5-bb6670adfa43@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 16:17:35 GMT, Kevin Rushforth  wrote:

>> @kevinrushforth Please take a look.
>
> @arapte Please wait for @tiainen or @johanvos to verify that it works in their build environment.

> @kevinrushforth I'll start a verification run.

Thank you. No rush...I just wanted to make sure it wasn't integrated without you having the chance to test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3462873914

From angorya at openjdk.org  Wed Oct 29 18:02:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 18:02:54 GMT
Subject: RFR: 8368478: RichTextArea: add IME support
In-Reply-To: <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>
References: 
 <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>
Message-ID: 

On Wed, 29 Oct 2025 12:55:57 GMT, Kevin Rushforth  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1438:
> 
>> 1436:      * @param sb the buffer to copy to
>> 1437:      * @param limit the maximum number of characters to copy, must be >= 0
>> 1438:      * @param lineSeparator the newline separator sequence, or null to use the platform default
> 
> Whether and how to add lineSeparator is under review via PR #1944. I recommend removing everything related to line separators for this PR, unless you want this PR to be dependent on #1944.

This and #1944 interrelated.  Ideally, this PR should go first.

> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1442:
> 
>> 1440:      * @since 26
>> 1441:      */
>> 1442:     // TODO depends on JDK-8370140 (line separator property), private for now
> 
> While a `getText(...)` method would be useful, I don't see an enhancement request that proposes it. I would make it more clear that this is not public API. If you want to leave the docs in place for a future enhancement that might provide such a public API, I recommend changing `@since 26` to `@since 99` (or similar).

correct, this is not a public API (yet).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2474425664
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2474429640

From michaelstrau2 at gmail.com  Wed Oct 29 18:03:51 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 29 Oct 2025 19:03:51 +0100
Subject: JEP Proposal: Fluent Bindings for multiple observables
In-Reply-To: 
References: 
Message-ID: 

I'm not too excited about the proposed syntax, because x.with(y) makes
it seem that x and y are not the same, it feels like an operation that
is performed on x. At least to me, something like
ObservableValue.tie(x, y).map((x, y) -> {...}) looks more intuitive.
But then the additional value on top of the existing
Bindings.create*Binding() may seem a bit marginal. On the other hand,
the null-eliding behavior may improve ergonomics a lot for some
people.

From angorya at openjdk.org  Wed Oct 29 18:12:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 18:12:36 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
Message-ID: 

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

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:

 - review comments
 - Merge branch 'master' into 8368478.ime
 - test
 - accessor
 - cleanup
 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8368478.ime
 - ime object
 - ime location
 - ime works
 - ... and 1 more: https://git.openjdk.org/jfx/compare/19d028f3...3bb8d850

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1938/files
  - new: https://git.openjdk.org/jfx/pull/1938/files/d269071b..3bb8d850

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

  Stats: 348 lines in 12 files changed: 179 ins; 36 del; 133 mod
  Patch: https://git.openjdk.org/jfx/pull/1938.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1938/head:pull/1938

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

From sykora at openjdk.org  Wed Oct 29 18:56:09 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 29 Oct 2025 18:56:09 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

All builds succeeded flawlessly.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3395475397

From jhendrikx at openjdk.org  Wed Oct 29 19:22:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Oct 2025 19:22:03 GMT
Subject: RFR: 8091429: ObservableList#replaceRange(int from, int to,
 Collection col) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 17:26:21 GMT, Kevin Rushforth  wrote:

> I can review this.
> 
> @hjohn If you're happy with the current `replaceRange` name (which seems good to me), can you update the JBS and PR title to reflect this?

@kevinrushforth Yeah, I think the name suggested by Michael captures the intent well, and offers the most flexible option for doing large element replacements.

I've updated the JBS and PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1937#issuecomment-3463437904

From jhendrikx at openjdk.org  Wed Oct 29 19:27:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Oct 2025 19:27:48 GMT
Subject: Integrated: 8370652: Control and ScrollPaneSkin should snap computed
 width/height values to prevent scrollbars appearing due to rounding
 errors
In-Reply-To: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
References: <-JWDd1DbZnvZULRpIbJJO2vFb1_WdoD5aitVy67caF4=.9057c118-2071-443b-935e-aed14b907ac6@github.com>
Message-ID: 

On Sat, 25 Oct 2025 09:26:33 GMT, John Hendrikx  wrote:

> This PR will snap the values returned by `ScrollPaneSkin`s compute methods, and `Control`s `layoutChildren` method to prevent scroll bars from showing up (when using the `AS_NEEDED` policy) due to subtle rounding errors.  The scroll pane internally will compare its own height (minus insets) with its content height, and determine if vertical (or horizontal) scroll bar needs to be shown.  If the values being compared are even slightly off (by a few ulp's in floating point terms) then it may conclude a scroll bar should be shown when it should not be.
> 
> See the sample program and video in the related JBS ticket.
> 
> Note: in many places we forget to resnap values after seemingly innocent floating point calculations (even when all values involved are snapped already, errors can be introduced).  It is out of scope for this PR to fix all of these.
> 
> Note 2: since we only want to fix a rounding error, `snapSpace` is used and not `snapSize` as the latter will ceil values which would make tiny errors worse if they are just one ulp above the desired value.

This pull request has now been integrated.

Changeset: bf76ed2a
Author:    John Hendrikx 
URL:       https://git.openjdk.org/jfx/commit/bf76ed2a6dd1dd74baf865e405690ce996699513
Stats:     8 lines in 2 files changed: 0 ins; 0 del; 8 mod

8370652: Control and ScrollPaneSkin should snap computed width/height values to prevent scrollbars appearing due to rounding errors

Reviewed-by: angorya, kcr

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

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

From kcr at openjdk.org  Wed Oct 29 19:28:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 19:28:45 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 
Message-ID: <_o0KGPhIQWBbLjiZ3rpowlEHk3f0aqrNP2rgKc2wph0=.d8ebf2d6-ec77-40af-bd5e-d5679925005d@github.com>

On Wed, 29 Oct 2025 18:12:36 GMT, Andy Goryachev  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> 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:
> 
>  - review comments
>  - Merge branch 'master' into 8368478.ime
>  - test
>  - accessor
>  - cleanup
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8368478.ime
>  - ime object
>  - ime location
>  - ime works
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/c7946b30...3bb8d850

LGTM. Tested on Windows (in addition to macOS which I tested earlier).

I left a follow-up comment about your added TODOs. I'll reapprove if you make any changes.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1938#pullrequestreview-3395713832

From kcr at openjdk.org  Wed Oct 29 19:28:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 19:28:47 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 <1socK2s0k_9TN91fcYRKV3kniaErxcw0HsftjwtH-lw=.a8dfdf68-77bf-4dd4-9ae3-3904dc796ae8@github.com>
 
Message-ID: 

On Wed, 29 Oct 2025 17:47:48 GMT, Andy Goryachev  wrote:

>> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 264:
>> 
>>> 262:             dy = f.snappedTopInset();
>>> 263: 
>>> 264:             p = f.rangeShape(start, end); // TODO new api, no null
>> 
>> Is this "TODO" really related to IME? If not, I recommend removing it.
>
> this code predates [JDK-8357594](https://bugs.openjdk.org/browse/JDK-8357594)
> Additional geometry-based Text/TextFlow APIs.  I am planning to migrate to the new API in a follow-up.
> 
> Created https://bugs.openjdk.org/browse/JDK-8370902

Thanks for filing the RFE. Since you aren't otherwise modifying this method in this PR, adding a random TODO like this seems like an unrelated change. Now if you meant to also add this comment to line 232 (the call to `f.getUnderlineShape(start, end)` that you added above), then I could see also adding a reminder here as well.

So I recommend either adding a similar comment on line 232, or removing the unrelated TODOs.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2475045338

From angorya at openjdk.org  Wed Oct 29 19:32:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 19:32:26 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 
Message-ID: <8GyU9I-HHJxiXyqlCQtMHzKDay49tn2JVong46ZpacE=.a4ece857-1180-408b-9808-22e421090ccb@github.com>

On Wed, 29 Oct 2025 18:12:36 GMT, Andy Goryachev  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> 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:
> 
>  - review comments
>  - Merge branch 'master' into 8368478.ime
>  - test
>  - accessor
>  - cleanup
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8368478.ime
>  - ime object
>  - ime location
>  - ime works
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/52ae1806...3bb8d850

Thank you for review!
I'd prefer to keep TODOs as they point to the areas that need improvement or further work.

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3463491811

From angorya at openjdk.org  Wed Oct 29 19:36:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 19:36:53 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v2]
In-Reply-To: 
References: 
Message-ID: <8ahkel7COcYVLP2i9qneuyFb4KfgBzd_KQyIMjJ0EqI=.38dda3ad-a505-497b-8d94-46851ede6736@github.com>

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

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/1950/files
  - new: https://git.openjdk.org/jfx/pull/1950/files/b23a881b..aa17616f

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

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

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

From kcr at openjdk.org  Wed Oct 29 19:46:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 19:46:21 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 
Message-ID: <_5Dp9NFO6rnEE4M8QJW1OFec1uu8KUgJDTfmD2OZg7E=.1364167d-ce18-47be-b3d5-b98bc3e77515@github.com>

On Wed, 29 Oct 2025 18:12:36 GMT, Andy Goryachev  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> 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:
> 
>  - review comments
>  - Merge branch 'master' into 8368478.ime
>  - test
>  - accessor
>  - cleanup
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8368478.ime
>  - ime object
>  - ime location
>  - ime works
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/5f3ce593...3bb8d850

> I'd prefer to keep TODOs as they point to the areas that need improvement or further work.

Then how about adding another TODO in the newly added method? That one is actually related to this PR, and is another place that (once this is integrated) you will want to change when you implement [JDK-8370902](https://bugs.openjdk.org/browse/JDK-8370902).

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/TextCell.java line 232:

> 230:             dy = f.snappedTopInset();
> 231: 
> 232:             p = f.getUnderlineShape(start, end);

Suggestion:

            p = f.getUnderlineShape(start, end); // TODO new api

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

PR Review: https://git.openjdk.org/jfx/pull/1938#pullrequestreview-3395788677
PR Review Comment: https://git.openjdk.org/jfx/pull/1938#discussion_r2475102754

From kcr at openjdk.org  Wed Oct 29 21:02:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Oct 2025 21:02:00 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 28 Oct 2025 11:33:43 GMT, Lukasz Kostyra  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.
>
> Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into isFocused_fix-8359899
>  - Adjust window focus management for Windows Glass

The code changes look reasonable to me. I did leave one question inline.

What is the best way to test this? Ideally, I'd like a way to locally force the case where a window cannot be made focusable and have that test check the value of `Stage::isFocused`, reporting it (incorrectly) as true without this fix and false with the fix. I would then like to click on the Window (as @beldenfox did), and verify that it now reports as true.

I was able to verify that I get a different failing error message when I run `StageFocusTest` with gradle daemon enabled. Without this fix, two test methods fail when they try to readback the color. With this fix, they report that the window doesn't have focus. So that seems to validate at least part of the fix.

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1959:

> 1957:         }
> 1958: 
> 1959:         ::ShowWindow(hWnd, visible ? SW_SHOWNA : SW_HIDE);

Is this change needed? I presume that the idea behind it is that if it is a focusable window, it will be activated anyway?

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

PR Review: https://git.openjdk.org/jfx/pull/1849#pullrequestreview-3396114193
PR Review Comment: https://git.openjdk.org/jfx/pull/1849#discussion_r2475365154

From mhanl at openjdk.org  Wed Oct 29 21:34:52 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Oct 2025 21:34:52 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
References: 
 
 <-SpajyniUs5I_itn5Y72klOqpf7likaCcrB9sdH76L0=.1b6ea2ab-050b-46e0-babb-616c1b2a6309@github.com>
Message-ID: 

On Mon, 13 Oct 2025 12:55:58 GMT, Marius Hanl  wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve javadoc
>
> There seems to be an intermediate test failure, maybe a race condition unrelated to this change:
> 
> 
> TaskEventTest > cancelledCalledAfterHandler() FAILED
>     org.opentest4j.AssertionFailedError: expected:  but was: 
>         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.AssertTrue.failNotTrue(AssertTrue.java:63)
>         at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
>         at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
>         at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:183)
>         at app//test.javafx.concurrent.TaskEventTest.cancelledCalledAfterHandler(TaskEventTest.java:410)

> @Maran23 In case you missed it, this is pending changes from you.
> 
>     1. I noted some final doc changes in [this comment above](#discussion_r2455868260).
> 
>     2. I had added an [earlier comment](#issuecomment-3393245504) about adding your perf test to the PR somewhere under `tests/performance`.

On my list, thanks for the reminder! Did not had any time the last days, but I saw all comments and suggestions!

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3464164859

From mhanl at openjdk.org  Wed Oct 29 21:34:53 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Oct 2025 21:34:53 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v3]
In-Reply-To: 
References: 
 
 
 <6XYWRtjY4DaBUL-_XH78NtJarsCjHsJCDoqI-_UFyD8=.49afd1e2-e672-4bf9-9294-4fea337b122c@github.com>
 
 
 
 
 <5DIKimfyXApjHrrZQu5Ta9QkPC_2DEFvtLDupE-T8H0=.0dd8dab2-2096-432f-b73c-47567adac052@github.com>
 
 
 <-mgFZHOpdPkuymRgAltwH5Ja24HblDRbE_1EX9h5XnU=.e5db5b74-9773-4a62-b914-545acd1c2ea5@github.com>
 
 
Message-ID: <3EeAzIAQlRJozDR6j6uqMWAQ1Rf_vurYF1LBXLuocIo=.58a1e6b3-0bbe-40da-af36-9d1e55a7d6de@github.com>

On Thu, 23 Oct 2025 16:19:13 GMT, Kevin Rushforth  wrote:

>> I like this idea.
>> If we want to explain what rebuild does, I would probably mention that this means the cells are updated. So maybe instead of `rebuild`, we could use something like `re-update`, maybe?
>
> @Maran23 Can you update the javadoc for the four methods as Andy suggested above (possibly with my simplification) and then update the CSR Specification section to match? I think that's the only remaining thing needed to move this forward.

> Discussed with Kevin yesterday, what do you think of this version:

I like it! Will update today.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1830#discussion_r2475577372

From angorya at openjdk.org  Wed Oct 29 21:54:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Oct 2025 21:54:17 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v3]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8366201.allow.undo
 - undo redo enabled logic
 - cleanup
 - cleanup
 - removed allow undo parameter
 - nl
 - test
 - append insert text
 - tests
 - ... and 1 more: https://git.openjdk.org/jfx/compare/48b57b54...ffe6894c

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/84d02951..ffe6894c

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

  Stats: 381 lines in 14 files changed: 215 ins; 33 del; 133 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

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

From mhanl at openjdk.org  Wed Oct 29 22:59:48 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Oct 2025 22:59:48 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v4]
In-Reply-To: 
References: 
 
Message-ID: <_5VAI97HLi-VTBtlohhIuPIQRJDWvGgvVfZFs6aXekc=.cd31768b-6fc4-41b5-a1b0-33aa8a503948@github.com>

On Mon, 13 Oct 2025 12:28:42 GMT, Marius Hanl  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).
>> 
>> ----
>> 
>> Benchmarks
>> -
>> 
>> Setup:
>> - `TableView`
>> - `100 TableColumns`
>> - `1000 Items`
>> 
>> Code is in `tests/performance`.
>> 
>> Calling `refresh()` with a `Button` press.
>> 
>> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
>> | - | - | - | - | - |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 0ms | 0 ms | 0 ms | 0 ms |
>> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
>> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
>> | Init | 2 ms | 6 ms | 6 ms | - |
>> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
>> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
>> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
>> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc

I was confused when rerunning the benchmarks because suddenly I got 3 `layoutChildren` calls without the fix.
Turns out that this is due to the fix made in https://github.com/openjdk/jfx/pull/1879 (JDK-8360940).

I made new benchmarks and edited the description:

Before fix & without JDK-8360940 | Before fix (master) | With fix | With fix & with JDK-8370498 |
| - | - | - | - |

It looks like with https://github.com/openjdk/jfx/pull/1945, the startup got a bit faster (which I think might be expected since we can save unnecessary layouts)

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3464739632

From mhanl at openjdk.org  Wed Oct 29 23:05:20 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Oct 2025 23:05:20 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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).
> 
> ----
> 
> Benchmarks
> -
> 
> Setup:
> - `TableView`
> - `100 TableColumns`
> - `1000 Items`
> 
> Code is in `tests/performance`.
> 
> Calling `refresh()` with a `Button` press.
> 
> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
> | - | - | - | - | - |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
> | Init | 2 ms | 6 ms | 6 ms | - |
> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |

Marius Hanl 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 branch 'master' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
 - javadoc and performance test
 - Improve javadoc
 - remove newline from imports
 - assert row creation count as well
 - Merge branch 'master' of https://github.com/openjdk/jfx into 8359599-refresh-recreates-all
 - Calling refresh() for all virtualized controls recreates all cells instead of refreshing the cells

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1830/files
  - new: https://git.openjdk.org/jfx/pull/1830/files/0575d6fb..ba5a9bab

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

  Stats: 2090 lines in 126 files changed: 1437 ins; 199 del; 454 mod
  Patch: https://git.openjdk.org/jfx/pull/1830.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1830/head:pull/1830

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

From mhanl at openjdk.org  Wed Oct 29 23:21:21 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Oct 2025 23:21:21 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

Just checked this out, and in the meantime Gradle got a new update again ? - https://docs.gradle.org/9.2.0/release-notes.html

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

PR Comment: https://git.openjdk.org/jfx/pull/1953#issuecomment-3464921792

From duke at openjdk.org  Thu Oct 30 07:18:24 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 30 Oct 2025 07:18:24 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: 
References: 
 
Message-ID: <9MaM2E-NB-K5lMwO4R3e9lkEczsYrRj3OYwRmfFf638=.009aca5d-d088-4cca-838a-28ada083961d@github.com>

On Wed, 22 Oct 2025 15:57:23 GMT, Pabulaner IV  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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 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
>  - 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
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m

As long as manual tests are considered a good practice in such cases, I would be fine with it.
This would of course mean that the test cases won't automatically detect if something doesn't work anymore.
Otherwise I see no problem with manual tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3466410558

From duke at openjdk.org  Thu Oct 30 07:44:36 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 30 Oct 2025 07:44:36 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v6]
In-Reply-To: 
References: 
Message-ID: 

> 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/358f670d..c5b5af07

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

  Stats: 134 lines in 9 files changed: 79 ins; 2 del; 53 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  Thu Oct 30 07:44:41 2025
From: duke at openjdk.org (Pabulaner IV)
Date: Thu, 30 Oct 2025 07:44:41 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 22 Oct 2025 15:57:23 GMT, Pabulaner IV  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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 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
>  - 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
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Overrides.m

So I have fixed Your minor merge issues and have converted the tests to manual tests. Maybe You can take a look and give me some feedback on what might need to be changed, since I don't know exactly what requirements manual tests need to satisfy.

PS: Sorry for the rebasing, I am used to this workflow from my work, but I will use merge in the future.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3466485569

From mhanl at openjdk.org  Thu Oct 30 08:11:34 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Oct 2025 08:11:34 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells [v6]
In-Reply-To: 
References: 
Message-ID: 

> 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).
> 
> ----
> 
> Benchmarks
> -
> 
> Setup:
> - `TableView`
> - `100 TableColumns`
> - `1000 Items`
> 
> Code is in `tests/performance`.
> 
> Calling `refresh()` with a `Button` press.
> 
> | WHAT | BEFORE WITHOUT JDK-8360940 | BEFORE | WITH FIX | WITH FIX WITH JDK-8370498 |
> | - | - | - | - | - |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 0ms | 0 ms | 0 ms | 0 ms |
> | Init | 195 ms | 209 ms | 211 ms | 217 ms |
> | Init | 42 ms | 47 ms | 41 ms | 10 ms |
> | Init | 2 ms | 6 ms | 6 ms | - |
> | Refresh Nr. 1 | 204 ms | 227 ms -> 23 ms -> 0 ms | 42 ms -> 0ms | 48 ms -> 0ms |
> | Refresh Nr. 2 | 201 ms | 145 ms -> 27 ms -> 0 ms | 31 ms -> 0ms | 35 ms -> 0ms |
> | Refresh Nr. 3 | 207 ms | 153 ms -> 25 ms | 33 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 4 | 148 ms | 168 ms -> 20 ms -> 0 ms | 30 ms -> 0ms | 31 ms -> 0ms |
> | Refresh Nr. 5 | 136 ms | 183 ms -> 31 ms -> 0 ms | 46 ms -> 0ms | 29 ms -> 0ms |

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

  add copyright

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1830/files
  - new: https://git.openjdk.org/jfx/pull/1830/files/ba5a9bab..27ad53c7

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

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

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

From jhendrikx at openjdk.org  Thu Oct 30 08:15:02 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Oct 2025 08:15:02 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
 
Message-ID: <96g22UbZKs8ZGiaTktbnHSQ1rvQu_5St7E4lTE40_bY=.fe3ff8ff-6ae3-4081-b6aa-b95d9f66665a@github.com>

On Wed, 29 Oct 2025 11:21:31 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   D3DTextureResource: Set resource to null after disposing

Marked as reviewed by jhendrikx (Reviewer).

I've added this fix to my application, and I don't know exactly how the resources are now managed, but it seems that it does solve the problem and the program no longer gets stuck in an NPE loop, even with more large images showing than usual.

Very happy with the fix, it was something I already looked into but didn't have time to further investigate :)

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

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3397909427
PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3466573951

From jvos at openjdk.org  Thu Oct 30 08:48:51 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 30 Oct 2025 08:48:51 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 <38VhzQ5qlXFCNUu8i7hr2PmhveYHULTh8CzyjHYhj14=.94d6a70a-cc49-407e-b880-83de81138ab8@github.com>
 
 <6V451ZFHR9kyFzlcCDNUpYyKVa2OalhnY3Xr2ssjy8g=.d3f27431-5a24-4897-844e-ad1390ccaee3@github.com>
 
 
 
 
Message-ID: 

On Tue, 28 Oct 2025 22:34:07 GMT, John Hendrikx  wrote:

> You mentioned that FX "promises to handle all edge cases". Do you care to show me where it does so? Because FX would be the first system with complex layouts that would be doing so.

That is a bit taken out of its context. My text said:

At least the layout system in JavaFX gives developers lots of freedom, and it promises to handle all edge cases. That fulfills the main goal (correct rendering, perhaps after a number of pulses, leading to flickering), but it makes the second goal (top-efficiency) really hard.

What I wanted to say with this is that the *current* handling gives priority to making sure things got rendered, and not to performance. If you want to change that, all good. I simply tried to give my reading of historical context, while trying to understand why things are the way they are.
Again, I'm not saying this should not be modified (rather the contrary). I had the impression you wondered about why it was like it was, and I tried to answer that. Sorry if that message came over a bit hyperbolic.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3466696378

From kcr at openjdk.org  Thu Oct 30 12:08:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 12:08:05 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 29 Oct 2025 11:06:15 GMT, Lukasz Kostyra  wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java line 91:
>> 
>>> 89:     public void update(MediaFrame frame, boolean skipFlush)
>>> 90:     {
>>> 91:         if (!resource.isValid()) {
>> 
>> related - D3DTextureResource line 40 is 
>> 
>> 
>>     public void free() {
>>         if (resource != null) {
>>             resource.dispose();
>>         }
>>     }
>> 
>> 
>> should there be `resource = null;` after `resource.dispose()` ?
>
> It could add another layer of safety and make any potential future NPEs more easy to track - I'll add this.

In looking more closely at the code, it looks like adding `resource = null` in `free()` is redundant, since every caller of `free()` already does it right after calling it. It doesn't seem harmful, though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2477855994

From kcr at openjdk.org  Thu Oct 30 12:18:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 12:18:18 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX [v5]
In-Reply-To: <9MaM2E-NB-K5lMwO4R3e9lkEczsYrRj3OYwRmfFf638=.009aca5d-d088-4cca-838a-28ada083961d@github.com>
References: 
 
 <9MaM2E-NB-K5lMwO4R3e9lkEczsYrRj3OYwRmfFf638=.009aca5d-d088-4cca-838a-28ada083961d@github.com>
Message-ID: 

On Thu, 30 Oct 2025 07:16:12 GMT, Pabulaner IV  wrote:

> As long as manual tests are considered a good practice in such cases, I would be fine with it. This would of course mean that the test cases won't automatically detect if something doesn't work anymore. Otherwise I see no problem with manual tests.

Exactly. Automated tests are preferred where feasible. This seems like a case where they aren't quite (which is too bad, since I liked the idea of your automated tests).

Manual tests seem fine in this case. I'll review and test them. Thanks.

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

PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3467709655

From lkostyra at openjdk.org  Thu Oct 30 12:27:25 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 30 Oct 2025 12:27:25 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: <96g22UbZKs8ZGiaTktbnHSQ1rvQu_5St7E4lTE40_bY=.fe3ff8ff-6ae3-4081-b6aa-b95d9f66665a@github.com>
References: 
 
 <96g22UbZKs8ZGiaTktbnHSQ1rvQu_5St7E4lTE40_bY=.fe3ff8ff-6ae3-4081-b6aa-b95d9f66665a@github.com>
Message-ID: 

On Thu, 30 Oct 2025 08:12:10 GMT, John Hendrikx  wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   D3DTextureResource: Set resource to null after disposing
>
> I've added this fix to my application, and I don't know exactly how the resources are now managed, but it seems that it does solve the problem and the program no longer gets stuck in an NPE loop, even with more large images showing than usual.
> 
> Very happy with the fix, it was something I already looked into but didn't have time to further investigate :)

@hjohn I wanted to do a more thorough check before making a response to your first comment.

The problem here is a use-after-free situation. `D3DVramPool` can prune and unlink a bunch of Textures (with `-Dprism.pooldebug=true` you can see a bunch of `unlinking: null (size=...)` messages). Right after that Prism tries to create a new RTT for rendering the next frame and `D3DResourceFactory` attempts to initialize it by first creating a temporary Graphics object and then calling `clear()` on it. This can cause a flush of pre-existing rendering data and can potentially trigger an update on a mask Texture that has just been pruned by the Pool. Here's the stack trace of this happening:

LKDEBUG Tried to update invalid resource at:
java.lang.Exception: Stack trace
        at java.base/java.lang.Thread.dumpStack(Thread.java:1991)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DTexture.update(D3DTexture.java:147)
        at javafx.graphics at 26-internal/com.sun.prism.impl.BaseContext.flushMask(BaseContext.java:115)
        at javafx.graphics at 26-internal/com.sun.prism.impl.BaseContext.drawQuads(BaseContext.java:124)
        at javafx.graphics at 26-internal/com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:98)
        at javafx.graphics at 26-internal/com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:107)
        at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.java:791)
        at javafx.graphics at 26-internal/com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:149)
        at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:107)
        at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:84)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DGraphics.(D3DGraphics.java:40)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DGraphics.create(D3DGraphics.java:63)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DRTTexture.createGraphics(D3DRTTexture.java:80)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DResourceFactory.createRTTexture(D3DResourceFactory.java:360)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DResourceFactory.createRTTexture(D3DResourceFactory.java:301)
        at javafx.graphics at 26-internal/com.sun.prism.d3d.D3DResourceFactory.createRTTexture(D3DResourceFactory.java:61)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSDrawable.create(PPSDrawable.java:59)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSRenderer.createCompatibleImage(PPSRenderer.java:218)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSRenderer.createCompatibleImage(PPSRenderer.java:67)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.ImagePool.checkOut(ImagePool.java:178)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.Renderer.getCompatibleImage(Renderer.java:120)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PPSRenderer.java:226)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSTwoSamplerPeer.filterImpl(PPSTwoSamplerPeer.java:62)
        at javafx.graphics at 26-internal/com.sun.scenario.effect.impl.prism.ps.PPSEffectPeer.filter(PPSEffectPeer.java:54)
        ...


The mask texture has been considered not needed anymore by other parts of Prism, but its reference still lingers in the Context. Since the rendering code considers the mask Texture as unnecessary, skipping that update has no effect on the rendering loop or the output.

Ideally I would expect to have the mask Texture detached from the Context when it gets considered unnecessary, but after a brief look into common Prism code (unless I missed something) I think it might not be as easy as it sounds. Mask Texture is created by `BaseContext` which will also locally store its reference for the purpose of potentially flushing it later - since that mask Texture is returned to other parts of Prism, those can eventually consider it unneeded and the VramPool will prune/unlink it, but the existing reference will occasionally still linger in `BaseContext`. I agree the check in this change is not ideal, but we would probably have to rework this code a bit to properly solve it. I feel like this area is also very fragile and any small change can do a butterfly effect thing and trigger some other special edge-case scenario...

An alternative solution I saw just now would be to put a check directly in `BaseContext.flushMask()` to verify if maskTex is valid before doing the lock-update-unlock sequence - then we will be sure no backend enters the update method when it would be done on an already freed object. I might add that check and do some extra testing before integrating this change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3467741288

From kcr at openjdk.org  Thu Oct 30 12:53:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 12:53:53 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v3]
In-Reply-To: 
References: 
 
Message-ID: <62ed9GCeRKvXH1fPyY4Cq17JCqlz8sUIa92e5PvhRSg=.b1b3b893-06aa-4938-aa0b-2b666bc5a97a@github.com>

On Wed, 29 Oct 2025 21:54:17 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> 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:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8366201.allow.undo
>  - undo redo enabled logic
>  - cleanup
>  - cleanup
>  - removed allow undo parameter
>  - nl
>  - test
>  - append insert text
>  - tests
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/08cea2b1...ffe6894c

I left a couple more doc comments. Otherwise the API docs look ready to go.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 441:

> 439:      * Replaces text in this CodeArea.
> 440:      * It creates an undo/redo entry if the model's
> 441:      * {@link StyledTextModel#isUndoRedoEnabled() isUndoRedoEnabled()} returns {@code true}.

I think it is cleaner to refer to the `isUndoRedoEnable()` method in _this_ class. No need to refer to the model here. Something like:

     * It creates an undo/redo entry if
     * {@link #isUndoRedoEnabled() isUndoRedoEnabled()} returns {@code true}.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1077:

> 1075:      * sequences result in a new paragraph being added.
> 1076:      * It creates an undo/redo entry if the model's
> 1077:      * {@link StyledTextModel#isUndoRedoEnabled() isUndoRedoEnabled()} returns {@code true}.

No need to refer to the model.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 634:

> 632:      * {@code start} position.
> 633:      * It creates an undo/redo entry if the model's
> 634:      * {@link StyledTextModel#isUndoRedoEnabled() isUndoRedoEnabled()} returns {@code true}.

Since this is a method in the model, saying "the model's ..." is not needed. Maybe just say:


     * It creates an undo/redo entry if
     * {@link #isUndoRedoEnabled() isUndoRedoEnabled()} returns {@code true}.


(like you did in a below method)

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 844:

> 842:      * Indicates whether undo/redo functionality is enabled.
> 843:      * @return true if undo/redo functionality is enabled
> 844:      * @since 26

Please add:


     * @defaultValue {@code true}

modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 796:

> 794:         assertTrue(control.isUndoable());
> 795:         control.setUndoRedoEnabled(false);
> 796:         assertFalse(control.isUndoable());

To check that the stack is actually cleared, you might want to re-enable undoRedo, append text, undo, check for "23", undo again, check that it is still "23".

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3399343298
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477917825
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477971753
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477929496
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477935045
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477902651

From kcr at openjdk.org  Thu Oct 30 12:58:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 12:58:56 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v3]
In-Reply-To: <62ed9GCeRKvXH1fPyY4Cq17JCqlz8sUIa92e5PvhRSg=.b1b3b893-06aa-4938-aa0b-2b666bc5a97a@github.com>
References: 
 
 <62ed9GCeRKvXH1fPyY4Cq17JCqlz8sUIa92e5PvhRSg=.b1b3b893-06aa-4938-aa0b-2b666bc5a97a@github.com>
Message-ID: 

On Thu, 30 Oct 2025 12:23:18 GMT, Kevin Rushforth  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 11 additional commits since the last revision:
>> 
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8366201.allow.undo
>>  - undo redo enabled logic
>>  - cleanup
>>  - cleanup
>>  - removed allow undo parameter
>>  - nl
>>  - test
>>  - append insert text
>>  - tests
>>  - ... and 1 more: https://git.openjdk.org/jfx/compare/d067a608...ffe6894c
>
> modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 796:
> 
>> 794:         assertTrue(control.isUndoable());
>> 795:         control.setUndoRedoEnabled(false);
>> 796:         assertFalse(control.isUndoable());
> 
> To check that the stack is actually cleared, you might want to re-enable undoRedo, append text, undo, check for "23", undo again, check that it is still "23".

GitHub is doing something odd here. In the Conversation view, it looks like I added this comment below line 772 (I didn't). If you look in the "Files" view (the diffs), you will see that I added it below line 796.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2477993144

From jhendrikx at openjdk.org  Thu Oct 30 13:37:49 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Oct 2025 13:37:49 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx  wrote:

>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test

> What I wanted to say with this is that the _current_ handling gives priority to making sure things got rendered (e.g. adding a second pulse in cases where it's not needed), and not to performance. If you want to change that, all good. I simply tried to give my reading of historical context, while trying to understand why things are the way they are. Again, I'm not saying this should not be modified (rather the contrary). I had the impression you wondered about why it was like it was, and I tried to answer that. Sorry if that message came over a bit hyperbolic.

Sorry, I definitely misinterpreted that and got a bit wound up about it.  

I'm however unsure how to proceed.  I don't think I can solve all the problems we've been seeing:
- Problem 1: Layout flags not being updated correctly, leading to layouts stop being updated (JDK-8360940) -- fixed by #1879 
- Problem 2: The problem Johan Vos posted in the mailing list where layout X/Y **always** gets modified twice, and although it converges to the same value each time, the layout X/Y logic will now always trigger another layout due to #1879 (before it would just get into a state where some things needed layout, but it wasn't propagated)
- Problem 3: The test program that binds on width/height properties in JDK-8137252 -- I'm dubious if that's worth supporting.  The fix was to always do a 2nd layout (as the `isCurrentLayoutChild` precondition doesn't actually work)
- Problem 4: The menu bar not working correctly (but that may be fixable)

Without any fixes, 2 + 3 + 4 works.

With just the layout flags fix 1 + 3 + 4 works.

With this PR 1 + 2 will work, and probably can get 4 fixed as well.

With this PR **and** perhaps always triggering another pass if a non-resizable control was modified, we may be able to get all of them working.  I however can't really see the logic why non-resizable controls should be an exception here, and if we can't also run into the same problems with a resizable control if I modified the example in JDK-8137252.

:-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3468039307

From lkostyra at openjdk.org  Thu Oct 30 13:46:52 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 30 Oct 2025 13:46:52 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage
 fails to receive focus [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <5dqRJNL_jk1DrmWFn3XfCtTg9dt7aeb9QacOIigw4qI=.b96d2941-19c4-42f5-9a1b-acadcde5504e@github.com>

On Wed, 29 Oct 2025 20:38:57 GMT, Kevin Rushforth  wrote:

>> Lukasz Kostyra has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into isFocused_fix-8359899
>>  - Adjust window focus management for Windows Glass
>
> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1959:
> 
>> 1957:         }
>> 1958: 
>> 1959:         ::ShowWindow(hWnd, visible ? SW_SHOWNA : SW_HIDE);
> 
> Is this change needed? I presume that the idea behind it is that if it is a focusable window, it will be activated anyway?

Yes, this is part of the fix. The values in question are:
- `SW_SHOW` - shows a window and activates it, sending the `WM_ACTIVATE` message
- `SW_SHOWNA` - shows a window but doesn't activate it - activation is postponed to us later calling `::SetForegroundWindow()`

By using `SW_SHOWNA` we can postpone the window activation and have `::SetForegroundWindow()` trigger it. If `::SetForegroundWindow()` succeeds, window gets activated and gains focus, and `WM_ACTIVATE` gets sent, which will then be captured by JavaFX message loop so we can notify Java-side that we gained focus. If `::SetForegroundWindow()` fails, we see that in this function and we can notify Java-side the focus has been lost.

This is unfortunately a bit hacky, but I couldn't find another way of establishing whether we actually have focus or not, especially combining that with what `::SetForegroundWindow()` returns. With `SW_SHOW` the `WM_ACTIVATE` message would go through despite `::SetForegroundWindow()` failing and us ultimately _not_ having focus.

My first attempt also considered leaving this part as-is and simply notifying Java-side if we lost focus or not based on `::SetForegroundWindow()` result, but that wasn't consistent. Postponing the window activation seemed to me as the best bet here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1849#discussion_r2478173850

From lkostyra at openjdk.org  Thu Oct 30 14:08:38 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 30 Oct 2025 14:08:38 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
> 
> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
> 
> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  BaseContext: Add maskTex checks to flushMask()

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1951/files
  - new: https://git.openjdk.org/jfx/pull/1951/files/f7c452e0..1e1832f3

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

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

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

From lkostyra at openjdk.org  Thu Oct 30 14:08:41 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 30 Oct 2025 14:08:41 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 11:21:31 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   D3DTextureResource: Set resource to null after disposing

Tests work well and the issue does not happen with the check in `BaseContext.flushMask()`.

I figured the checks in `D3DTexture` can also stay - they are redundant in context of this specific bug, but they also won't hurt.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3468191199

From angorya at openjdk.org  Thu Oct 30 14:34:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 14:34:59 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BaseContext: Add maskTex checks to flushMask()

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3399959306

From mhanl at openjdk.org  Thu Oct 30 15:04:44 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Oct 2025 15:04:44 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 13:35:06 GMT, John Hendrikx  wrote:

> With this PR 1 + 2 will work, and probably can get 4 fixed as well.

I would prefer this option. 
In my opinion, it is worth pursuing this option because it improves consistency, performance and simply makes sense to me.
The previous behavior felt like an oversight that just worked accidently.

I wonder if we need to combine what Johan said: Having warnings (if easily possible) for things you should rather not do.
For example, reading what you wrote above:

>  Modifying CSS during layout (which changes anything size or position related) is a guaranteed jump of your UI as a next pass is required
> For example, you also should not be modifying the scene graph during layout, because if you say add a new child (like a list cell or something) that cell will be rendered without styles
 
This is good information I even did not know in full detail (although it looks like I made this correct for my own components, because I did what JavaFX is doing). 
Having warnings or information for that would be nice. Since we now can detect correctly when we layout children, we may can detect is something triggered another CSS pass although it should better not do that now, and what to do instead. This way, even is something now breaks, we could get information why this unusual combination does not work as expected.

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3468472862

From angorya at openjdk.org  Thu Oct 30 15:22:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 15:22:14 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v4]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/ffe6894c..2d5db54e

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

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

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

From kcr at openjdk.org  Thu Oct 30 15:35:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 15:35:06 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 15:22:14 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks good apart from one stray "the" in one of the methods.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 440:

> 438:     /**
> 439:      * Replaces text in this CodeArea.
> 440:      * It creates an undo/redo entry if the

Remove the stray `the` at the end of this line.

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3400252816
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2478557155

From angorya at openjdk.org  Thu Oct 30 15:39:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 15:39:06 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v5]
In-Reply-To: 
References: 
Message-ID: <_Z7gbFiWm3GJ_CJtRQSEAIB6nBUdv56EmA3HGNHh2HE=.397e2cd4-a8c0-498c-acce-296109056c42@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  the

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/2d5db54e..361088e5

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

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

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

From kcr at openjdk.org  Thu Oct 30 16:03:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 16:03:17 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v5]
In-Reply-To: <_Z7gbFiWm3GJ_CJtRQSEAIB6nBUdv56EmA3HGNHh2HE=.397e2cd4-a8c0-498c-acce-296109056c42@github.com>
References: 
 <_Z7gbFiWm3GJ_CJtRQSEAIB6nBUdv56EmA3HGNHh2HE=.397e2cd4-a8c0-498c-acce-296109056c42@github.com>
Message-ID: <3T2JLFFFHh_jmSTMVF3fAwAcNWVvGtv0opti-JdssqU=.4082c423-a5bb-40d1-aa39-35e073a370e6@github.com>

On Thu, 30 Oct 2025 15:39:06 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   the

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3400410798

From kcr at openjdk.org  Thu Oct 30 16:50:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 16:50:54 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BaseContext: Add maskTex checks to flushMask()

Since this has expanded beyond D3D we will need to test it on all platforms. Also, it may be that you have found the root cause of [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629), which @arapte filed to track the root cause of a similar bug (his was a crash rather than an NPE),  [JDK-8368631](https://bugs.openjdk.org/browse/JDK-8368631), that caused him to add the check for valid texture resource in `MTLTexture`.

If you can verify that this does indeed fix [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629), then it might be better to close [JDK-8352209](https://bugs.openjdk.org/browse/JDK-8352209) as a duplicate and change the title of this PR to point to use [JDK-8368629](https://bugs.openjdk.org/browse/JDK-8368629). If not, it still seems worth changing the title of this PR (and JBS issue) to something more generic.

Also, what do you think about adding the null assignment to the ES2 pipeline?

modules/javafx.graphics/src/main/java/com/sun/prism/impl/BaseContext.java line 111:

> 109: 
> 110:     protected final void flushMask() {
> 111:         if (maskTex != null && maskTex.isSurfaceLost()) return;

if maskText is null the subsequent calls could throw NPE, so maybe this should be:


        if (maskTex == null || maskTex.isSurfaceLost()) return;

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

PR Review: https://git.openjdk.org/jfx/pull/1951#pullrequestreview-3400224223
PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2478535551

From angorya at openjdk.org  Thu Oct 30 17:39:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 17:39:18 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/361088e5..187678ff

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

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

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

From jhendrikx at openjdk.org  Thu Oct 30 18:08:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Oct 2025 18:08:46 GMT
Subject: RFR: 8370498: Improve how Node detects whether a layout property
 change requires a new layout pass [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 30 Oct 2025 15:01:55 GMT, Marius Hanl  wrote:

> This is good information I even did not know in full detail (although it looks like I made this correct for my own components, because I did what JavaFX is doing).
> Having warnings or information for that would be nice. Since we now can detect correctly when we layout children, we may can detect is something triggered another CSS pass although it should better not do that now, and what to do instead. This way, even is something now breaks, we could get information why this unusual combination does not work as expected.

Yeah, I discovered this one in a dark-mode application, where I was adding new cells (on demand) during layout, and I noticed a brief white flash.  Solved it with `Scene::addPreLayoutListener`.  No idea what the virtual flows do :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3469370242

From angorya at openjdk.org  Thu Oct 30 19:48:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 19:48:25 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v3]
In-Reply-To: 
References: 
Message-ID: 

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> NOTE:
> - this PR and #1938 are interrelated; it's probably better for #1938 to go first.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into 8370140.line.separator
 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - tests
 - line endings

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=02
  Stats: 261 lines in 13 files changed: 232 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

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

From angorya at openjdk.org  Thu Oct 30 19:52:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 19:52:51 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v4]
In-Reply-To: 
References: 
Message-ID: 

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> NOTE:
> - this PR and #1938 are interrelated; it's probably better for #1938 to go first.

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

  since

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/2d7dbbb9..7c3b1079

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

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

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

From kcr at openjdk.org  Thu Oct 30 22:26:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 22:26:23 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v2]
In-Reply-To: 
References: 
 <8RiPJ6U7I7MzDpYG3gqC123-U99ahQd398hTDKw8dqo=.49ad9845-f231-408a-a2d4-a3a28a6793ea@github.com>
 
Message-ID: 

On Tue, 28 Oct 2025 22:12:52 GMT, Kevin Rushforth  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   undo redo enabled logic
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1865:
> 
>> 1863: 
>> 1864:     /**
>> 1865:      * Replaces the specified range with the new input.  This method creates an undo entry.
> 
> It creates an undo/redo entry if the undoRedo attribute is `true`.

Still pending.

Another place to add `if {@link #isUndoRedoEnabled()} returns {@code true}`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2479660740

From kcr at openjdk.org  Thu Oct 30 22:26:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 22:26:20 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 17:39:18 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

While reviewing the CSR I found 3 more places where you missed adding `if {@link #isUndoRedoEnabled()} returns {@code true}` to a method that creates an undo/redo entry.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1160:

> 1158: 
> 1159:     /**
> 1160:      * Clears the document, creating an undo/redo entry.

Another place to add `if {@link #isUndoRedoEnabled()} returns {@code true}`

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1860:

> 1858: 
> 1859:     /**
> 1860:      * Replaces the specified range with the new text.  This method creates an undo entry.

Another place to add `if {@link #isUndoRedoEnabled()} returns {@code true}`

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

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3401847653
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2479659148
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2479659974

From angorya at openjdk.org  Thu Oct 30 22:36:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 22:36:24 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 17:39:18 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

I wonder if it might be better to remove these notes from all the editing methods in the control (since all of them call the model), and keep the notes in the model.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3470491866

From kcr at openjdk.org  Thu Oct 30 22:36:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Oct 2025 22:36:25 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 22:23:30 GMT, Kevin Rushforth  wrote:

> While reviewing the CSR I found 3 more places where you missed adding `if {@link #isUndoRedoEnabled()} returns {@code true}` to a method that creates an undo/redo entry.

As discussed offline, another option is to remove all mention of "creates an undo/redo entry" from the RichTextArea methods, since those all forward it to the model, and it is the model that creates and tracks the undo/redo entries.

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

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3470492447

From kizune at openjdk.org  Thu Oct 30 22:41:24 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 22:41:24 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 18:12:36 GMT, Andy Goryachev  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> 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:
> 
>  - review comments
>  - Merge branch 'master' into 8368478.ime
>  - test
>  - accessor
>  - cleanup
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8368478.ime
>  - ime object
>  - ime location
>  - ime works
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/0a8ae3be...3bb8d850

Marked as reviewed by kizune (Committer).

I have tested couple of input methods including Japanese (Mozc) in different modes. In general the input method works and i was able to do the typing reasonably well but the editing sometimes leaves strange artifacts - especially when cancelling the suggestion - there is an underline text that was a raw input before suggestions and if you delete this text the underline stays but you can't navigate to that place as if there is no text but when window loses focus the raw input symbols re-appear in this place.

Also whenever i am trying to commit a suggestion the following warning pops in the terminal where i started the application:

(java:4993): IBUS-WARNING **: 15:31:22.791: ibus_input_context_post_process_key_event: Type 'h' is not supported.

Not sure what it is about.
I recorded the video that demonstrates the issue with the cancelled input but i do not think that this is a blocker for the feature.
[Screencast from 2025-10-30 15-31-14.webm](https://github.com/user-attachments/assets/ad7fff10-181b-48b9-9074-30496dd9e71e)

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

PR Review: https://git.openjdk.org/jfx/pull/1938#pullrequestreview-3401892121
PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3470500292

From angorya at openjdk.org  Thu Oct 30 22:46:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 22:46:21 GMT
Subject: RFR: 8368478: RichTextArea: add IME support [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 29 Oct 2025 18:12:36 GMT, Andy Goryachev  wrote:

>> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
>> 
>> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
>> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
>> 
>> For testing, one can use the updated Monkey Tester
>> https://github.com/andy-goryachev-oracle/MonkeyTest
>> (optionally enable IME events in stdout with Logging -> IME Monitor)
>
> 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:
> 
>  - review comments
>  - Merge branch 'master' into 8368478.ime
>  - test
>  - accessor
>  - cleanup
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8368478.ime
>  - ime object
>  - ime location
>  - ime works
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/2d6f014f...3bb8d850

Does it show the same artifacts with a regular TextArea?

The video does not seem to show the composition popup.

On macOS, I noticed that Japanese IME works slightly different from Pinyin - you actually need to commit (or it thinks that it's still editing, I am not sure).

Also, you can try enabling the Logging -> IME Monitor in the latest monkey tester and see what linux IME generates - on macOS, I could not do left arrow while in IME, and backspace simply removes the character and the dotted line underneath it.  Could it be some bug in IME/Linux?

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

PR Comment: https://git.openjdk.org/jfx/pull/1938#issuecomment-3470521867

From angorya at openjdk.org  Thu Oct 30 23:10:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Oct 2025 23:10:14 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v7]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  undo/redo javadoc in model only

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/187678ff..4170fbff

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

  Stats: 19 lines in 3 files changed: 3 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

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

From mstrauss at openjdk.org  Fri Oct 31 00:07:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 31 Oct 2025 00:07:46 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: 
References: 
Message-ID: 

> Adds the `Dialog.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style. The property is ignored for all other stage styles.

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

  move HeaderBar to DialogPane

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1943/files
  - new: https://git.openjdk.org/jfx/pull/1943/files/52360ffb..c85e8bb6

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

  Stats: 274 lines in 6 files changed: 133 ins; 125 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1943.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1943/head:pull/1943

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

From barbara.salinas at tec.mx  Fri Oct 31 00:23:46 2025
From: barbara.salinas at tec.mx (=?utf-8?B?TWFyw61hIELDoXJiYXJhIFNhbGluYXMgTHVuYQ==?=)
Date: Fri, 31 Oct 2025 00:23:46 +0000
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi OpenJFX ?

I am a 57 years old IT Teacher, I am learning Java and JavaFX, as I have some doubts I requested to enter to your distribution list, so I could ask my doubts, but I am receiving many emails everyday and I could see that all of you are experts programming with JavaFX ;)

I think I should look for a different way to ask my biginner doubts, that?s why I am respectfully asking you to delete my name from your distribution list.

It was a pleasure to read you for few days, I would like to have more time to study much more about JavaFX so I could become an expert like you, for sure I'll do that in the future ;)

Thanks in advance for your kind attention, have a nice afternoon ?


Master Ma. B?rbara Salinas Luna

Profesora de planta

Departamento de Ciencias

Preparatoria Esmeralda

Campus Estado de M?xico

Tecnol?gico de Monterrey


Tel. +55 5864 5370

barbara.salinas at tec.mx


________________________________
From: openjfx-dev  on behalf of Andy Goryachev 
Sent: Thursday, October 30, 2025 4:36 PM
To: openjfx-dev at openjdk.org 
Subject: Re: RFR: 8366201: RichTextArea: remove allowUndo parameter [v6]

On Thu, 30 Oct 2025 17:39:18 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.org%2Fpipermail%2Fopenjfx-discuss%2F2025-August%2F000267.html&data=05%7C02%7Cbarbara.salinas%40tec.mx%7C8692f3db4ee14304fffa08de18052523%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C638974607546251784%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K0ZSjEG9KQdMhNSRzSFl7TlZZbW8RK8IgmLMF%2F%2BW%2FCA%3D&reserved=0 ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>>
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>>
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>>
>> WARNING this is an incompatible change, permitted because of the incubator.
>>
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8370447&data=05%7C02%7Cbarbara.salinas%40tec.mx%7C8692f3db4ee14304fffa08de18052523%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C638974607546282964%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6rmGP4bqJqO%2FyImDQKAYI7ARDdGzUg3tXt%2FzX6xepYc%3D&reserved=0 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>
>   javadoc

I wonder if it might be better to remove these notes from all the editing methods in the control (since all of them call the model), and keep the notes in the model.

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

PR Comment: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.openjdk.org%2Fjfx%2Fpull%2F1941%23issuecomment-3470491866&data=05%7C02%7Cbarbara.salinas%40tec.mx%7C8692f3db4ee14304fffa08de18052523%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C638974607546302303%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MwGMq%2B6BvrjHXOMQvxh6bCKPhnvB5SUN2k%2FHymQVo6A%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstrauss at openjdk.org  Fri Oct 31 00:51:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 31 Oct 2025 00:51:21 GMT
Subject: RFR: 8370446: Support dialogs with StageStyle.EXTENDED [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 00:07:46 GMT, Michael Strau?  wrote:

>> Adds the `DialogPane.headerBar` property, which allows developers to specify a custom `HeaderBar` when the dialog uses the `EXTENDED` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HeaderBar to DialogPane

I've moved the new API from `Dialog` (which roughly corresponds to a `Stage`) to `DialogPane`, which contains the scene graph of a dialog. All bugs you've found should also be fixed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1943#issuecomment-3470867748

From jbhaskar at openjdk.org  Fri Oct 31 03:29:23 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 31 Oct 2025 03:29:23 GMT
Subject: Integrated: 8370235: WebKit build fails on Windows 32-bit and Linux
 32-bit after JDK-8367578
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 03:19:41 GMT, Jay Bhaskar  wrote:

> Issue: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578
> Solution: [JSC] Use llintOpWithReturn for instanceof on 32-bits
> https://github.com/WebKit/WebKit/commit/05f6e3818e1be6d1186ebfd5e059f669361edf0a

This pull request has now been integrated.

Changeset: ef387fc2
Author:    Jay Bhaskar 
URL:       https://git.openjdk.org/jfx/commit/ef387fc2b0899a2a32f79e3b8454dce69f094a03
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8370235: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578

Reviewed-by: kcr, hmeda

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

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

From jbhaskar at openjdk.org  Fri Oct 31 07:10:51 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 31 Oct 2025 07:10:51 GMT
Subject: [jfx25u] RFR: 8370235: WebKit build fails on Windows 32-bit and Linux
 32-bit after JDK-8367578
Message-ID: 

A clean backport for jfx25u. The fix is for WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578. The build fails without fix and passes with fix.

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

Commit messages:
 - Backport ef387fc2b0899a2a32f79e3b8454dce69f094a03

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

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

From lkostyra at openjdk.org  Fri Oct 31 11:06:31 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 31 Oct 2025 11:06:31 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <2FWS9tiiKQMpTOs88Czu4dXoe-27anWId3ppau-1Dog=.b0e85d3d-fd3c-4658-b64c-376d1a4ed77c@github.com>

On Thu, 30 Oct 2025 15:22:59 GMT, Kevin Rushforth  wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BaseContext: Add maskTex checks to flushMask()
>
> modules/javafx.graphics/src/main/java/com/sun/prism/impl/BaseContext.java line 111:
> 
>> 109: 
>> 110:     protected final void flushMask() {
>> 111:         if (maskTex != null && maskTex.isSurfaceLost()) return;
> 
> if maskTex is null the subsequent calls could throw NPE, so maybe this should be:
> 
> 
>         if (maskTex == null || maskTex.isSurfaceLost()) return;

Fair point. I think this code works regardless because originally `maskTex` was supposed to be guarded by `curMaskRow` and `curMaskCol` below being set to zero.

I will change it to the above.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1951#discussion_r2481051890

From nlisker at openjdk.org  Fri Oct 31 11:12:22 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 31 Oct 2025 11:12:22 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
Message-ID: <7ZJDY-l4MlLWfzsy4pmCd2Pk4_HDcIsY2H4K7mUUjsE=.ccb51ce5-cce8-4f6c-9156-77a7d634c5ae@github.com>

On Thu, 30 Oct 2025 14:08:38 GMT, Lukasz Kostyra  wrote:

>> This PR fixes NPE thrown when trying to update D3D texture in some rare scenarios.
>> 
>> On more stressful cases (like the one using Canvas attached to this issue) it is possible that a D3DTexture.update() call will go through after the Resource Pool already pruned the underlying Texture's resource. This in turn caused an NPE, which propagated to higher levels and disrupted the rendering loop, causing the Canvas to not be drawn anymore. The update() call seems not to be called more than once on an already freed resource, suggesting this is some sort of rare race between the pool and the drawing code.
>> 
>> This change prevents the NPE from being thrown. I noticed no visual problems with the test even when the update() call is rejected by the newly added check. Best way to verify it is to add a log call inside added `if (!resource.isValid())` blocks when running the test, it will occasionally get printed but the test itself won't change its behavior like it does without this change.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BaseContext: Add maskTex checks to flushMask()

A more general question: what is the condition for the release of the resource/texture? Does it come from a native call, reference count or something else? It feels like there should be a strict mechanism for this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3472563993

From jbhaskar at openjdk.org  Fri Oct 31 11:24:24 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 31 Oct 2025 11:24:24 GMT
Subject: [jfx25u] Integrated: 8370235: WebKit build fails on Windows 32-bit and
 Linux 32-bit after JDK-8367578
In-Reply-To: 
References: 
Message-ID: 

On Fri, 31 Oct 2025 07:00:57 GMT, Jay Bhaskar  wrote:

> A clean backport for jfx25u. The fix is for WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578. The build fails without fix and passes with fix.

This pull request has now been integrated.

Changeset: 4dc1a521
Author:    Jay Bhaskar 
URL:       https://git.openjdk.org/jfx25u/commit/4dc1a52164becea9c2bb2ca1567bbeb863061d0a
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8370235: WebKit build fails on Windows 32-bit and Linux 32-bit after JDK-8367578

Backport-of: ef387fc2b0899a2a32f79e3b8454dce69f094a03

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

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

From lkostyra at openjdk.org  Fri Oct 31 13:27:21 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 31 Oct 2025 13:27:21 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 30 Oct 2025 16:48:31 GMT, Kevin Rushforth  wrote:

> Also, what do you think about adding the null assignment to the ES2 pipeline?

I think it wouldn't hurt, it would be an additional safeguard. I also can't really imagine the scenario where we would drop an update that is otherwise necessary - if we do then that's a separate memory management issue, as in we freed something that we still need to use.

> A more general question: what is the condition for the release of the resource/texture? Does it come from a native call, reference count or something else? It feels like there should be a strict mechanism for this.

This is unfortunately a question I don't have a definitive answer for yet. I was looking into this yesterday after I wrote my initial comment, but it is quite difficult to trace down the exact cause.

My current running theory is that mask textures are considered to be temporary (if you look at ex. `BaseShaderGraphics.renderShape()` it gets unlocked right after adding a shape to render) and eventually - once the Pool runs out of space while processing something else - said texture can get pruned by the Pool since it is unlocked. But, the rendering call that updates it has not been submitted yet, only a quad was added by `renderShape()` to the VertexBuffer. Next time the VertexBuffer gets flushed we attempt to prepare the mask for the upcoming VertexBuffer flush and end up trying to use-after-free like I described above.

If that is indeed the case this could require a more serious fix - we would have to make sure that the mask stays locked while it is waiting in `BaseContext` for rendering so that the Pool doesn't prune it before VertexBuffer is flushed. That would probably require a more serious rework and a bunch more testing to get it right and ensure no stale references stay in the Pool. I might add this to JBS as a follow-up investigation and enhancement/rework.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3473083887

From nlisker at openjdk.org  Fri Oct 31 14:28:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 31 Oct 2025 14:28:03 GMT
Subject: RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 31 Oct 2025 13:24:32 GMT, Lukasz Kostyra  wrote:

> I might add this to JBS as a follow-up investigation and enhancement/rework.

This would be a good idea. If the condition for the release of the texture is that the VertexBuffer has been flushed, we might need an upcall to notify the pool to dereference the texture.

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

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3473332143

From mhanl at openjdk.org  Fri Oct 31 14:34:24 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 31 Oct 2025 14:34:24 GMT
Subject: RFR: 8370883: Update boot JDK to 25.0.1
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Oct 2025 13:57:39 GMT, Ambarish Rapte  wrote:

> Update boot jdk to 25.0.1, along with gradle update to version 9.1.0.
> The gradle 9 related deprecation are already addressed with [JDK-8360586](https://bugs.openjdk.org/browse/JDK-8360586)

Also worked with the newest Gradle version 9.2.0 for me!
image

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1953#pullrequestreview-3404580992

From mfox at openjdk.org  Fri Oct 31 16:19:41 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 31 Oct 2025 16:19:41 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

There was a request to merge in the latest master but this PR is also marked as ready. Should I go ahead with the merge?

The SizingTest failures on macOS with StageStyle.EXTENDED are due to some weirdness in the OS. When we set the minimum size on an EXTENDED window the OS simply adds 16 units to the minimum height (I can verify this by writing the minSize and then immediately reading it back). I'm still trying to figure out where this magic number comes from. For EXTENDED we add a toolbar but the minimum size of a toolbar is 28 units. In any case I think this is a separate issue. I'll do a bit more research and file a bug.

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

PR Comment: https://git.openjdk.org/jfx/pull/1870#issuecomment-3473826824

From angorya at openjdk.org  Fri Oct 31 16:26:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 16:26:37 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

there are no merge conflicts, you can integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1870#issuecomment-3473857901

From andy.goryachev at oracle.com  Fri Oct 31 17:29:29 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 31 Oct 2025 17:29:29 +0000
Subject: RichTextArea Feedback
Message-ID: 

Dear Jurgen:

Thank you for the feedback!  Let's see if I could give a satisfactory response.

> In RichParagraph you have a note to make getSegments() public.

Yes, either this list must be made immutable (by adding some overhead) or we could add getSegmentCount() and getSegmentAt(int).  Created RFE https://bugs.openjdk.org/browse/JDK-8371070

> When an INLINE_NODE in RichTextArea is updated and it triggers
requestLayout then the request doesn't propagate all the way up to VFlow
but stops when it reaches TextCell.

Interesting, I'll need to investigate.  Created https://bugs.openjdk.org/browse/JDK-8371067

> When a paragraph ends with an INLINE_NODE and one tries to go to the end
of the line/paragraph (either via API or K/B end) then the caret moves
to the starting position of the node and not after it.

Support for inline nodes is not yet complete, see https://bugs.openjdk.org/browse/JDK-8365948
Created https://bugs.openjdk.org/browse/JDK-8371067 to address this specific scenario.

> As expected though paste and undo/redo don't work due to
StyledTextModel's final replace method not handling INLINE_NODE's

This is correct, and I think it might be better to leave up to the (custom) model.  The reason for it is it should be up to the application/custom model to decide how to deal with the embedded nodes, especially interactive ones.

There exists a special case of embedding images - images are a binary objects that can be easily duplicated, copied, exported, and pasted.  See https://bugs.openjdk.org/browse/JDK-8365949

Did I miss anything?  Please let me know.

And keep that feedback coming!

Cheers,
-andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From angorya at openjdk.org  Fri Oct 31 18:32:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 18:32:30 GMT
Subject: Integrated: 8368478: RichTextArea: add IME support
In-Reply-To: 
References: 
Message-ID: 

On Thu, 16 Oct 2025 19:59:06 GMT, Andy Goryachev  wrote:

> Adds Input Method Editor (IME) support to `RichTextArea`/`CodeArea`.
> 
> Tested on macOS and Windows 11 with Japanese and Chinese (pinyin) input methods.
> Please test this on Linux, even though there is no platform-specific code in this PR (should work the same way it does in `TextArea`/`TextField`)
> 
> For testing, one can use the updated Monkey Tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
> (optionally enable IME events in stdout with Logging -> IME Monitor)

This pull request has now been integrated.

Changeset: 5d069436
Author:    Andy Goryachev 
URL:       https://git.openjdk.org/jfx/commit/5d069436ebaf0394f4c91b838f86b9391b618296
Stats:     575 lines in 9 files changed: 494 ins; 56 del; 25 mod

8368478: RichTextArea: add IME support

Reviewed-by: kcr, kizune, lkostyra

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

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

From angorya at openjdk.org  Fri Oct 31 18:39:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 18:39:36 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v5]
In-Reply-To: 
References: 
Message-ID: <9ENS-49T2P0X6UGMaLhbRbpvK6qoL4-dp0tn6Z2vrFY=.adce7f80-fde0-4413-8584-6d1765f69b9a@github.com>

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> NOTE:
> - this PR and #1938 are interrelated; it's probably better for #1938 to go first.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8370140.line.separator
 - since
 - Merge branch 'master' into 8370140.line.separator
 - Merge remote-tracking branch 'origin/master' into 8370140.line.separator
 - tests
 - line endings

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

Changes: https://git.openjdk.org/jfx/pull/1944/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1944&range=04
  Stats: 262 lines in 13 files changed: 234 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jfx/pull/1944.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1944/head:pull/1944

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

From kcr at openjdk.org  Fri Oct 31 18:48:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Oct 2025 18:48:24 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Aug 2025 17:23:43 GMT, Martin Fox  wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double notifications, keep window min/max/normal state unchanged.

A primary reason for merging master in a PR whose source branch is out of date is to catch any problems that might arise due to semantic conflicts. Skara and GitHub do a pretty good job of catching merge conflicts, but there can be semantically conflicting changes even if there are no git merge conflicts.

This is 70 commits behind, so merging master is a good idea. It will trigger a GHA run, which isn't conclusive, but is at least a first pass indicator. If it is a clean merge, there will be no need to re-review.

Having said that, I did my testing using a branch in my repo where I merged in master as of two weeks ago (I always do that when I run CI tests) and didn't see any problems, so if you're confident that there won't be a problem, you can integrate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1870#issuecomment-3474436662

From angorya at openjdk.org  Fri Oct 31 18:48:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 18:48:57 GMT
Subject: RFR: 8370140: RichTextArea: line endings [v6]
In-Reply-To: 
References: 
Message-ID: 

> Adds control of line endings (newline separators) in `StyledTextModel`, `RichTextArea`, and `CodeArea`.
> 
> The impacted areas are:
> - saving to plain text
> - copying to plain text
> - IME
> 
> This feature is implemented as a regular field in the `StyledTextModel` (since it is ultimately an attribute of the model), and as a property in the `CodeArea`.
> 
> NOTE:
> - some dependency on #1938 , resolved.

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

  get text

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1944/files
  - new: https://git.openjdk.org/jfx/pull/1944/files/b9a496e2..994e6788

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

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

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

From mfox at openjdk.org  Fri Oct 31 19:07:24 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 31 Oct 2025 19:07:24 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v3]
In-Reply-To: 
References: 
Message-ID: 

> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
> 
> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.

Martin Fox 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 'upstream/master' into sendcorrectsize
 - Remove double notifications, keep window min/max/normal state unchanged.
 - If min/max window size enforced send notification to correct Window properties
 - Merge remote-tracking branch 'upstream/master' into sendcorrectsize
 - Comment cleanup
 - Notify WindowStage if setBounds didn't change the size as expected

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1870/files
  - new: https://git.openjdk.org/jfx/pull/1870/files/468fd354..c270bff8

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

  Stats: 900761 lines in 10082 files changed: 382955 ins; 393786 del; 124020 mod
  Patch: https://git.openjdk.org/jfx/pull/1870.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1870/head:pull/1870

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

From kcr at openjdk.org  Fri Oct 31 19:40:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Oct 2025 19:40:21 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 30 Oct 2025 23:10:14 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo/redo javadoc in model only

You missed removing one of the mentions of undo in `CodeArea::setText`, but otherwise looks good.

There is a merge conflict in the test that you will need to resolve.

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 446:

> 444:     public final void setText(String text) {
> 445:         TextPos end = getDocumentEnd();
> 446:         getModel().replace(null, TextPos.ZERO, end, text);

The javadoc description for this method still says "an undo event gets created".

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

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3405856713
PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2482477381

From angorya at openjdk.org  Fri Oct 31 19:52:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 19:52:33 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v8]
In-Reply-To: 
References: 
Message-ID: <6sTLMew7kKxXcl8dvBY_BPTJ9vBSKcABgaDr0nWr7aY=.6ea6fd98-0f05-426b-9590-04c01d4be6f2@github.com>

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8366201.allow.undo
 - undo/redo javadoc in model only
 - javadoc
 - the
 - review comments
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8366201.allow.undo
 - undo redo enabled logic
 - cleanup
 - cleanup
 - ... and 6 more: https://git.openjdk.org/jfx/compare/5d069436...415abf7e

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

Changes: https://git.openjdk.org/jfx/pull/1941/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=07
  Stats: 314 lines in 17 files changed: 239 ins; 6 del; 69 mod
  Patch: https://git.openjdk.org/jfx/pull/1941.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1941/head:pull/1941

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

From angorya at openjdk.org  Fri Oct 31 19:58:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 19:58:19 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 31 Oct 2025 19:31:05 GMT, Kevin Rushforth  wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   undo/redo javadoc in model only
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 446:
> 
>> 444:     public final void setText(String text) {
>> 445:         TextPos end = getDocumentEnd();
>> 446:         getModel().replace(null, TextPos.ZERO, end, text);
> 
> The javadoc description for this method still says "an undo event gets created".

this is one place where I do want to mention the undo event.
How about:

     * The caret gets reset to the start of the document, selection gets cleared,
     * and an undo event is created if {@link #isUndoRedoEnabled()} returns {@code true}.


?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2482526667

From angorya at openjdk.org  Fri Oct 31 20:18:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 20:18:04 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v9]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  set text

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/415abf7e..68d7524a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=07-08

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

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

From angorya at openjdk.org  Fri Oct 31 20:38:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 20:38:46 GMT
Subject: RFR: 8366202: RichTextArea: wrong style used for typed text [v3]
In-Reply-To: 
References: 
Message-ID: 

> User feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ):
> 
> When typing text, in the middle of a sentence, to extend a word that's styled then the typed text is not being inserted using the styles of the preceding text.
> 
> Root cause: implementation bug.

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

 - Merge branch 'master' into 8366202.wrong
 - review comments
 - wrong style

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1950/files
  - new: https://git.openjdk.org/jfx/pull/1950/files/aa17616f..643f97ef

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

  Stats: 816 lines in 16 files changed: 593 ins; 72 del; 151 mod
  Patch: https://git.openjdk.org/jfx/pull/1950.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1950/head:pull/1950

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

From kcr at openjdk.org  Fri Oct 31 21:23:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Oct 2025 21:23:21 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 20:18:04 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set text

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 442:

> 440:      * 

> 441:      * The caret gets reset to the start of the document, selection gets cleared,
> 442:      * and an undo event is created if {@link #isUndoRedoEnabled()} returns {@code true}.

This is at odd with all the other recent changes you did, where you intentionally removed all such mentions in the control.

Suggestion:

     * The caret gets reset to the start of the document and the selection gets cleared.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1941#discussion_r2482703182

From angorya at openjdk.org  Fri Oct 31 21:39:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 21:39:56 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v10]
In-Reply-To: 
References: 
Message-ID: 

> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
> 
> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
> 
> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
> 
> WARNING this is an incompatible change, permitted because of the incubator.
> 
> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .

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

  suggestion
  
  Co-authored-by: Kevin Rushforth 

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1941/files
  - new: https://git.openjdk.org/jfx/pull/1941/files/68d7524a..878429e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1941&range=08-09

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

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

From andy.goryachev at oracle.com  Fri Oct 31 21:47:59 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 31 Oct 2025 21:47:59 +0000
Subject: RichTextArea missing Caspian entries
In-Reply-To: <3CCA52F5-ECBF-42FF-99F3-B44A5D0437FD@getmailspring.com>
References: <3CCA52F5-ECBF-42FF-99F3-B44A5D0437FD@getmailspring.com>
Message-ID: 

I am afraid the Caspian CSS is effectively unmaintained since jfx 9 or so.  All the changes and fixes go to Modena.

I wonder if we should deprecate Caspian (not for removal).

May I ask why you are using Caspian and not Modena?  Is there something missing or got worse in Modena?

In any case, created https://bugs.openjdk.org/browse/JDK-8371080

Thanks!
-andy


From: openjfx-discuss  on behalf of Jurgen Doll 
Date: Friday, October 31, 2025 at 01:40
To: openjfx-discuss at openjdk.org 
Subject: RichTextArea missing Caspian entries

Hi Andy

Just a heads up that Caspian CSS doesn't have the entries for RichTextArea etc.

Thanks, regards
Jurgen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kcr at openjdk.org  Fri Oct 31 21:58:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Oct 2025 21:58:21 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v10]
In-Reply-To: 
References: 
 
Message-ID: <6mnjsw4oXZgnXrAaXcd19xBMhBppGa0QmKaOvRnu_NQ=.d6f4f4b1-8517-4242-818e-6f00074d40ec@github.com>

On Fri, 31 Oct 2025 21:39:56 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion
>   
>   Co-authored-by: Kevin Rushforth 

LGTM

I'll review the CSR once you propagate the latest javadoc changes.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1941#pullrequestreview-3406304337
PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3475005328

From angorya at openjdk.org  Fri Oct 31 22:46:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 31 Oct 2025 22:46:23 GMT
Subject: RFR: 8366201: RichTextArea: remove allowUndo parameter [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 31 Oct 2025 21:39:56 GMT, Andy Goryachev  wrote:

>> Original user feedback (see https://mail.openjdk.org/pipermail/openjfx-discuss/2025-August/000267.html ) called for adding an `allowUndo` parameter to `applyStyle()` and `setStyle()` methods similarly to `replaceText()`.
>> 
>> Upon further analysis, the `allowUndo` parameter was a mistake: allowing the application code to disable creating undo/redo entries messes up the internal undo/redo stack.
>> There is an internal need (`UndoableChange`), but it should not be exposed via public API.
>> 
>> This PR also adds `isUndoRedoEnabled()` and `setUndoRedoEnabled()` to the `StyledTextModel`, as well as its forwarding aliases to `RichTextArea` to allow for the application to disable undo/redo temporarily, for example, when building a document from multiple segments.
>> 
>> WARNING this is an incompatible change, permitted because of the incubator.
>> 
>> There remains a possible issue with currently unlimited size of the undo/redo stack - perhaps we should limit its depth to maybe 100-200 entries, see https://bugs.openjdk.org/browse/JDK-8370447 .
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion
>   
>   Co-authored-by: Kevin Rushforth 

@jayathirthrao could you be the second reviewer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1941#issuecomment-3475102657

From mfox at openjdk.org  Fri Oct 31 23:03:25 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 31 Oct 2025 23:03:25 GMT
Subject: Integrated: 8364547: Window size may be incorrect when constrained to
 min or max
In-Reply-To: 
References: 
Message-ID: <5Gw_u-JK9HChMyj4tu-m4sh6u3S4VmGLOELzXXlj6ck=.aa97e718-4fe2-408e-b048-5857d70e6190@github.com>

On Thu, 14 Aug 2025 16:26:07 GMT, Martin Fox  wrote:

> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
> 
> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.

This pull request has now been integrated.

Changeset: c77c2335
Author:    Martin Fox 
URL:       https://git.openjdk.org/jfx/commit/c77c2335856a967907aaacc9546f44943c069add
Stats:     21 lines in 2 files changed: 21 ins; 0 del; 0 mod

8364547: Window size may be incorrect when constrained to min or max

Reviewed-by: kcr, angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1870