From mstrauss at openjdk.org Thu Jan 1 10:28:48 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 1 Jan 2026 10:28:48 GMT Subject: RFR: 8369836: Update HeaderBar API [v8] In-Reply-To: References: Message-ID: <1IjYgQoN46aecvpM8apMsIiuavLAUuydryzmSBVvxX8=.ec19393e-42a5-47ae-b80a-e6d32869b836@github.com> > 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: HeaderDragType.TRANSPARENT/TRANSPARENT_SUBTREE ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/6cf87e00..aa8ce81d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=06-07 Stats: 300 lines in 5 files changed: 237 ins; 21 del; 42 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 michaelstrau2 at gmail.com Thu Jan 1 10:31:48 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 1 Jan 2026 11:31:48 +0100 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: I've given this some more thought, and I think we can do something in terms of API. What makes your use case different is that the occluder is not a descendant of the HeaderBar, instead it's a sibling of it. I've added HeaderDragType.TRANSPARENT and HeaderDragType.TRANSPARENT_SUBTREE, which can also be set on non-descendants of HeaderBar. Notably, it doesn't create additional draggable areas, it merely doesn't obstruct already-existing draggable areas. In your example, you would set TRANSPARENT on the MaskerPane. You can check it out in the HeaderBar API update PR: https://github.com/openjdk/jfx/pull/1936 Does this solve your problem? On Wed, Dec 31, 2025 at 2:24?AM Cormac Redmond wrote: > > Hi Michael, > > It could be adapted, it could also be clipped using the size of the HeaderBar (in fact, that's what I've done), etc. But MaskerPane was just an example that highlights differences in behaviour of Window icons vs draggable header. > > In this case, there are no controls in the HeaderBar and there are no controls sitting on top of it. There's just one pane sitting on another, and a lot of blank space. > > Scene's pickHeaderArea() does receive these mouse events. I am thinking that HeaderBar could/should, as much as possible, continue to support dragging when an event was not sourced from a control. I have never experienced an application that does not drag when you click and drag from an "empty" area of the header bar, wouldn't it be better to support this out-of-the-box (or at least an option to enable an eager more)? > > I imagine most HeaderBar usages won't be packed with nodes and would want this behaviour. > > Kind Regards, > Cormac From credmond at certak.com Thu Jan 1 20:59:53 2026 From: credmond at certak.com (Cormac Redmond) Date: Thu, 1 Jan 2026 20:59:53 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi Michael, Thanks for that. I tried it out and it does appear to work, which is great. Whether or not you should keep this configuration option permanently, is up for discussion though, I suppose. As mentioned previously, I managed to overcome my "issue" first by clipping the sibling (masker) pane, and also by manually disabling nodes in the HeaderBar as needed; having done that, I realised it looks a bit more natural to otherwise leave the main HeaderBar visually unaffected by such a masking pane (i.e., opaquing a window's title and title bar and window icons, etc., because the window is busy, isn't great UX -- in hindsight). All that said, *I have found some other bug*, or at least odd behaviour, however, which I suspect pre-dates this branch; the top vertical resize cursor does not appear under some conditions. Easiest to explain with a gif & code, keep an eye on the cursor over the green and red areas: [image: bug_hb.gif] Oddly, setting draggable in the red Center2 node affects whether or not the cursor appears there (when hovering over the red part, close enough to the border). It never appears for the green area, and does appear on Left and Right labels. I suspect this behaviour is related to Pane vs Control (HBox vs Label) in some way. Reproducer: public class NoDragCursorIssue extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { final HeaderBar headerBar = new HeaderBar(); headerBar.setLeft(new Label("Left")); final Label draggableLabel = new Label("Center2 Draggable"); final HBox c = new HBox(new Label("Center"), draggableLabel); HeaderBar.setDragType(draggableLabel, HeaderDragType.DRAGGABLE_SUBTREE); draggableLabel.setStyle("-fx-background-color: lightcoral;"); c.setAlignment(Pos.CENTER); c.setStyle("-fx-background-color: lightgreen;"); headerBar.setCenter(c); headerBar.setRight(new Label("Right")); headerBar.setStyle("-fx-background-color: lightblue;"); //HeaderBar.setDragType(headerBar.getRight(), HeaderDragType.DRAGGABLE_SUBTREE); BorderPane mainContent = new BorderPane(new BorderPane(new Label("center")), headerBar, null, null, null); primaryStage.initStyle(StageStyle.EXTENDED); primaryStage.setScene(new Scene(mainContent, 600, 400)); primaryStage.show(); } } Kind Regards, Cormac On Thu, 1 Jan 2026 at 10:32, Michael Strau? wrote: > I've given this some more thought, and I think we can do something in > terms of API. What makes your use case different is that the occluder > is not a descendant of the HeaderBar, instead it's a sibling of it. > I've added HeaderDragType.TRANSPARENT and > HeaderDragType.TRANSPARENT_SUBTREE, which can also be set on > non-descendants of HeaderBar. Notably, it doesn't create additional > draggable areas, it merely doesn't obstruct already-existing draggable > areas. In your example, you would set TRANSPARENT on the MaskerPane. > > You can check it out in the HeaderBar API update PR: > https://github.com/openjdk/jfx/pull/1936 > > Does this solve your problem? > > > > On Wed, Dec 31, 2025 at 2:24?AM Cormac Redmond > wrote: > > > > Hi Michael, > > > > It could be adapted, it could also be clipped using the size of the > HeaderBar (in fact, that's what I've done), etc. But MaskerPane was just an > example that highlights differences in behaviour of Window icons vs > draggable header. > > > > In this case, there are no controls in the HeaderBar and there are no > controls sitting on top of it. There's just one pane sitting on another, > and a lot of blank space. > > > > Scene's pickHeaderArea() does receive these mouse events. I am thinking > that HeaderBar could/should, as much as possible, continue to support > dragging when an event was not sourced from a control. I have never > experienced an application that does not drag when you click and drag from > an "empty" area of the header bar, wouldn't it be better to support this > out-of-the-box (or at least an option to enable an eager more)? > > > > I imagine most HeaderBar usages won't be packed with nodes and would > want this behaviour. > > > > Kind Regards, > > Cormac > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_hb.gif Type: image/gif Size: 28986 bytes Desc: not available URL: From michaelstrau2 at gmail.com Thu Jan 1 21:33:47 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 1 Jan 2026 22:33:47 +0100 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi Cormac, that's not a bug: On Windows, the top resize border is inside of the window, while the other three resize borders are outside of the window. You only get a resize cursor if the area below the cursor is draggable, which your green HBox is not. If you make it draggable, then you'll also get a resize cursor. This is by design, as the resize border shouldn't overlap client elements (in our case, elements that are not draggable). The fact that you get a resize cursor for the top edge of the red label looks like it may have something to do with the fact that it's a label, but in reality the label is just placed close enough to the top edge of the window so that the resize border extends a tiny bit over the label (which is draggable). -------------- next part -------------- An HTML attachment was scrubbed... URL: From credmond at certak.com Thu Jan 1 22:17:22 2026 From: credmond at certak.com (Cormac Redmond) Date: Thu, 1 Jan 2026 22:17:22 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi, This doesn't quite make sense to me, the Left and Right have a resize cursor, and neither of those are set as draggable. I guess it's because of their height/placement. E.g., see left versus right (Label versus HBox) in slightly tweaked code. E.g.: [image: curs.gif] So this brings me to another problem. We don't want some nodes to be draggable, such as the MenuBar. Because if it is, we end up with this: [image: menu.gif] And if you make it *non-draggable*, you lose the resize cursor (in IntelliJ, you get both non-drag behaviour, and resize cursor above the menu). It seems very confusing and non-intuitive; this relationship between dragging options and seeing a resize cursor and how they're incompatible re: the menu example. public class MenuCursorIssue extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { MenuBar menuBar = new MenuBar(); final Menu file = new Menu("File"); file.getItems().addAll(new Menu("New"), new Menu("Open")); menuBar.getMenus().addAll(file, new Menu("Edit")); Region region = new Region(); HBox.setHgrow(region, Priority.ALWAYS); // HeaderBar.setDragType(menuBar, HeaderDragType.DRAGGABLE_SUBTREE); HeaderBar.setDragType(region, HeaderDragType.DRAGGABLE_SUBTREE); HBox menuHbox = new HBox(menuBar, region); final HeaderBar headerBar = new HeaderBar(); headerBar.setCenter(menuHbox); primaryStage.initStyle(StageStyle.EXTENDED); primaryStage.setScene(new Scene(new BorderPane(new Label("center"), headerBar, null, null, null), 600, 400)); primaryStage.show(); } } Kind Regards, Cormac On Thu, 1 Jan 2026 at 21:41, Michael Strau? wrote: > Hi Cormac, > > that's not a bug: On Windows, the top resize border is inside of the > window, while the other three resize borders are outside of the window. You > only get a resize cursor if the area below the cursor is draggable, which > your green HBox is not. If you make it draggable, then you'll also get a > resize cursor. This is by design, as the resize border shouldn't overlap > client elements (in our case, elements that are not draggable). > > The fact that you get a resize cursor for the top edge of the red label > looks like it may have something to do with the fact that it's a label, but > in reality the label is just placed close enough to the top edge of the > window so that the resize border extends a tiny bit over the label (which > is draggable). > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: curs.gif Type: image/gif Size: 7059 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: menu.gif Type: image/gif Size: 31945 bytes Desc: not available URL: From credmond at certak.com Thu Jan 1 22:40:43 2026 From: credmond at certak.com (Cormac Redmond) Date: Thu, 1 Jan 2026 22:40:43 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: One other point: if the MenuBar is DRAGGABLE, there's no resize cursor and it's also not actually draggable, it must be DRAGGABLE_SUBTREE). On Thu, 1 Jan 2026 at 22:17, Cormac Redmond wrote: > Hi, > > This doesn't quite make sense to me, the Left and Right have a resize > cursor, and neither of those are set as draggable. I guess it's because of > their height/placement. E.g., see left versus right (Label versus HBox) in > slightly tweaked code. > > E.g.: > > [image: curs.gif] > > So this brings me to another problem. We don't want some nodes to be > draggable, such as the MenuBar. Because if it is, we end up with this: > > [image: menu.gif] > > And if you make it *non-draggable*, you lose the resize cursor (in > IntelliJ, you get both non-drag behaviour, and resize cursor above the > menu). It seems very confusing and non-intuitive; this relationship between > dragging options and seeing a resize cursor and how they're incompatible > re: the menu example. > > public class MenuCursorIssue extends Application { > public static void main(String[] args) { launch(args); } > > @Override > public void start(Stage primaryStage) { > > MenuBar menuBar = new MenuBar(); > final Menu file = new Menu("File"); > file.getItems().addAll(new Menu("New"), new Menu("Open")); > > menuBar.getMenus().addAll(file, new Menu("Edit")); > > Region region = new Region(); > HBox.setHgrow(region, Priority.ALWAYS); > // HeaderBar.setDragType(menuBar, > HeaderDragType.DRAGGABLE_SUBTREE); > > HeaderBar.setDragType(region, HeaderDragType.DRAGGABLE_SUBTREE); > HBox menuHbox = new HBox(menuBar, region); > > final HeaderBar headerBar = new HeaderBar(); > headerBar.setCenter(menuHbox); > > primaryStage.initStyle(StageStyle.EXTENDED); > primaryStage.setScene(new Scene(new BorderPane(new > Label("center"), headerBar, null, null, null), 600, 400)); > primaryStage.show(); > } > } > > > > > > Kind Regards, > Cormac > > On Thu, 1 Jan 2026 at 21:41, Michael Strau? > wrote: > >> Hi Cormac, >> >> that's not a bug: On Windows, the top resize border is inside of the >> window, while the other three resize borders are outside of the window. You >> only get a resize cursor if the area below the cursor is draggable, which >> your green HBox is not. If you make it draggable, then you'll also get a >> resize cursor. This is by design, as the resize border shouldn't overlap >> client elements (in our case, elements that are not draggable). >> >> The fact that you get a resize cursor for the top edge of the red label >> looks like it may have something to do with the fact that it's a label, but >> in reality the label is just placed close enough to the top edge of the >> window so that the resize border extends a tiny bit over the label (which >> is draggable). >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: curs.gif Type: image/gif Size: 7059 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: menu.gif Type: image/gif Size: 31945 bytes Desc: not available URL: From credmond at certak.com Thu Jan 1 22:53:56 2026 From: credmond at certak.com (Cormac Redmond) Date: Thu, 1 Jan 2026 22:53:56 +0000 Subject: HeaderBar consuming click with DRAGGABLE_SUBTREE (when focus lost and gained) Message-ID: Hi, I've noticed this behaviour as follows with a HeaderBar stage and MenuBar. If you make the JFX window lose focus, but still keep it visible, note the Menu items are responding to mouse hovers. But the first click is always ignored (i.e., no menu shown). This can be more frustrating than it may sound, when dealing with a lot of popups and secondary window hopping, etc. I assume this is not limited to MenuBar either. Example and code below. I will browse to Notepad to lose focus. The red circle you see is a click, see how it requires two clicks for the menu to appear when coming back from Notepad. Note this is not the behaviour for "Normal Menu", a menu not inside HeaderBar. [image: menu_focus.gif] public class MenuClickIssue extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { MenuBar hbMenu = getMenuBar("HeaderBar Menu"); HeaderBar.setDragType(hbMenu, HeaderDragType.DRAGGABLE_SUBTREE); Region region = new Region(); HBox.setHgrow(region, Priority.ALWAYS); HeaderBar.setDragType(region, HeaderDragType.DRAGGABLE_SUBTREE); HBox menuHbox = new HBox(hbMenu, region); final HeaderBar headerBar = new HeaderBar(); headerBar.setCenter(menuHbox); primaryStage.initStyle(StageStyle.EXTENDED); primaryStage.setScene(new Scene(new BorderPane(getMenuBar("Normal Menu"), headerBar, null, null, null), 600, 400)); primaryStage.show(); } private MenuBar getMenuBar(String title) { MenuBar hbMenu = new MenuBar(); final Menu file = new Menu(title); file.getItems().addAll(new Menu("New"), new Menu("Open")); hbMenu.getMenus().addAll(file, new Menu("Edit")); return hbMenu; } } Kind Regards, Cormac -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: menu_focus.gif Type: image/gif Size: 213715 bytes Desc: not available URL: From duke at openjdk.org Fri Jan 2 00:46:11 2026 From: duke at openjdk.org (duke) Date: Fri, 2 Jan 2026 00:46:11 GMT Subject: Withdrawn: 8369049: [TestBug] Update JUnit to Version 6.0.1 In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl wrote: > JUnit 6.0.1 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 > https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.1 > > 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 pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1925 From crschnick at xpipe.io Fri Jan 2 02:52:20 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 2 Jan 2026 03:52:20 +0100 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> <3312da0d-1d47-45dc-86af-92b59097cd35@xpipe.io> <2f4fc5fb-9d25-4f04-9606-383f260bffaf@xpipe.io> Message-ID: Figured out the problem. We were shipping 26+ea-3 in the last version and then bumped it to 26+ea-19. When distributing applications through an .msi, e.g. via jpackage, the msi will by default only replace files if certain conditions are met like the file version being different. (https://learn.microsoft.com/en-gb/windows/win32/msi/replacing-existing-files) Since all JavaFX ea releases are marked as v26.0.0.0 when taking a look at the properties of the shipped JavaFX .dlls, the msi installer does not guarantee that it will upgrade the older JavaFX dlls as they both have the same version. That way, some people might end up with the wrong dlls after an update. I am still not sure why this only happens to some users though. I don't think this is a JavaFX issue really, more of an unfortunate default behavior of msis. On 30/12/2025 18:23, Michael Strau? wrote: > UnsatisfiedLinkError will never be thrown from native code. > > In general, there's not much we can do about these kinds of > configuration errors. > Crashing is probably the best outcome here (a worse outcome would be > behavioral differences). > > > On Tue, Dec 30, 2025 at 5:59?PM Christopher Schnick wrote: >> Ah okay, I thought this could also be thrown from within the native >> method GlassWindow::SetDarkFrame when it calls a dwmapi.dll function and >> that dll is somehow broken or non-standard. If that is not possible, >> then you can ignore this and I will file that as broken user system. From michaelstrau2 at gmail.com Fri Jan 2 12:14:20 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 2 Jan 2026 13:14:20 +0100 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: > This doesn't quite make sense to me, the Left and Right have a resize cursor, and neither of those are set as draggable. I guess it's because of their height/placement. E.g., see left versus right (Label versus HBox) in slightly tweaked code. In your example, "left" and "right" are Labels, which don't resize to fill the available space. There's empty space above the label, and this empty space is the HeaderBar itself, which is draggable. This is why you get a resize cursor, the label has nothing to do with it. > So this brings me to another problem. We don't want some nodes to be draggable, such as the MenuBar. Because if it is, we end up with this: > > And if you make it non-draggable, you lose the resize cursor (in IntelliJ, you get both non-drag behaviour, and resize cursor above the menu). It seems very confusing and non-intuitive; this relationship between dragging options and seeing a resize cursor and how they're incompatible re: the menu example. How do you suggest we solve this? Just forcing a resize border over potentially interactive elements might work for some applications, but not for others. Windows File Explorer and Terminal generally have the same behavior, where you don't get a resize cursor on client content. However, they do seem to allow for a resize cursor if you manage to precisely hit the top border of the window (it seems you need pixel-precise pointing for that). However, tiny resize borders don't seem to be a good user experience. In general, you can of course recreate the IntelliJ behavior by simply placing a draggable, but visually transparent node across your MenuBar, aligned with the top of the HeaderBar and its height set to match the resize border. This will intercept mouse events and give you a resize cursor. From michaelstrau2 at gmail.com Fri Jan 2 12:24:09 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 2 Jan 2026 13:24:09 +0100 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: > One other point: if the MenuBar is DRAGGABLE, there's no resize cursor and it's also not actually draggable, it must be DRAGGABLE_SUBTREE). Yes, this is to be expected for most controls with non-trivial skins (i.e. skins that have inner nodes). Since DRAGGABLE is not inherited, inner nodes won't be draggable. It's almost always better to use DRAGGABLE_SUBTREE to include the entire substructure of the control. From michaelstrau2 at gmail.com Fri Jan 2 13:05:42 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 2 Jan 2026 14:05:42 +0100 Subject: HeaderBar consuming click with DRAGGABLE_SUBTREE (when focus lost and gained) In-Reply-To: References: Message-ID: > I've noticed this behaviour as follows with a HeaderBar stage and MenuBar. > > If you make the JFX window lose focus, but still keep it visible, note the Menu items are responding to mouse hovers. But the first click is always ignored (i.e., no menu shown). This can be more frustrating than it may sound, when dealing with a lot of popups and secondary window hopping, etc. I assume this is not limited to MenuBar either. > > Example and code below. I will browse to Notepad to lose focus. The red circle you see is a click, see how it requires two clicks for the menu to appear when coming back from Notepad. Note this is not the behaviour for "Normal Menu", a menu not inside HeaderBar. You've set an interactive element (the MenuBar) to be draggable, that's the source of problem. I don't think that it's worth supporting the specific scenario of click activation, as you'll soon run into even more problems (for example, you can drag away the window under an open menu. Interactive draggable elements is simply not a supported configuration. Maybe I should explicitly point this out in the documentation. From mstrauss at openjdk.org Fri Jan 2 13:19:29 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Jan 2026 13:19:29 GMT Subject: RFR: 8369836: Update HeaderBar API [v9] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/aa8ce81d..6b9f5b41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=07-08 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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 Jan 2 13:28:56 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Jan 2026 13:28:56 GMT Subject: RFR: 8369836: Update HeaderBar API [v10] In-Reply-To: References: Message-ID: <1FMj-0mPSD4tvG7j1Lz4qWCqUhgQ3Ry88YNL2TViciU=.45660aba-0196-4f4d-9997-711d024e3cfe@github.com> > 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/6b9f5b41..44c216bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=08-09 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 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 credmond at certak.com Fri Jan 2 13:34:39 2026 From: credmond at certak.com (Cormac Redmond) Date: Fri, 2 Jan 2026 13:34:39 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi, On my Windows system, I can *almost* as easily get the resize cursor above tabs (assuming that's what you mean by "client content") in Explorer and Terminal, though it seems to be less sensitive over the tabs, but there's at least a couple vertical pixels where it's selectable. It's similar for the Window icons: top left is Explorer (resize cursor appears over Window icons), bottom right is a JFX app (no resize cursor). I can resize if I need to: [image: resize.gif] In my opinion, the resize cursor, and its behaviour (when and how it appears), could firstly be separate to anything related to the draggable settings (or documented clearly if not already; as it's confusing to stumble upon this and wonder what the semantics are and why, of even if the cursor's absence has anything at all to do with JavaFX or the HeaderBar). E.g., to the average developer, they're probably not going to understand or think about the resize cursor, or where the top border *actually* is, etc., and consider/code for the differences between it and the other borders, and variance in behavior across OSs. They will just think it's useful that they can now place nodes in the title bar and expect/hope for the usual border semantics (or worse, not notice a regression). I imagine, if asked, developers would want a resize cursor to appear 99.9% of the time; *even* if it gets in the way of an interactive control (if they have important clickable parts that are that close to the border, then so be it). Or, alternatively, even if it appears less easily in places where controls are pushed up against the border. For example, I'm clicking on the menu here in IntelliJ, and no menu is showing. A good 1/3rd of the node is not selectable. I don't think that's bad UX, everybody is used to this and they can see the resize cursor, this is familiar: we know this is what happens near the borders. [image: no_menu.gif] If I had a short-ish, unpadded and borderless button, for example, pushed up against the top border, I'd still prefer to see a resize cursor appear uniformly and by default, even if it meant half the button was non-clickable. It's bad UX of course and easily fixed with some padding. So as a default, I feel the resize cursor should be present in some form, always, and it *should* be allowed to get in the way of interactive nodes -- not the other way around, in my opinion. Or some control over it would be great, for cases where this is not desirable behavior. I'm always just considering ease-of-use. Kind Regards, Cormac On Fri, 2 Jan 2026 at 12:36, Michael Strau? wrote: > > This doesn't quite make sense to me, the Left and Right have a resize > cursor, and neither of those are set as draggable. I guess it's because of > their height/placement. E.g., see left versus right (Label versus HBox) in > slightly tweaked code. > > In your example, "left" and "right" are Labels, which don't resize to > fill the available space. There's empty space above the label, and > this empty space is the HeaderBar itself, which is draggable. This is > why you get a resize cursor, the label has nothing to do with it. > > > > So this brings me to another problem. We don't want some nodes to be > draggable, such as the MenuBar. Because if it is, we end up with this: > > > > And if you make it non-draggable, you lose the resize cursor (in > IntelliJ, you get both non-drag behaviour, and resize cursor above the > menu). It seems very confusing and non-intuitive; this relationship between > dragging options and seeing a resize cursor and how they're incompatible > re: the menu example. > > How do you suggest we solve this? Just forcing a resize border over > potentially interactive elements might work for some applications, but > not for others. Windows File Explorer and Terminal generally have the > same behavior, where you don't get a resize cursor on client content. > However, they do seem to allow for a resize cursor if you manage to > precisely hit the top border of the window (it seems you need > pixel-precise pointing for that). However, tiny resize borders don't > seem to be a good user experience. > > In general, you can of course recreate the IntelliJ behavior by simply > placing a draggable, but visually transparent node across your > MenuBar, aligned with the top of the HeaderBar and its height set to > match the resize border. This will intercept mouse events and give you > a resize cursor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no_menu.gif Type: image/gif Size: 73848 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: resize.gif Type: image/gif Size: 40978 bytes Desc: not available URL: From credmond at certak.com Fri Jan 2 13:39:49 2026 From: credmond at certak.com (Cormac Redmond) Date: Fri, 2 Jan 2026 13:39:49 +0000 Subject: HeaderBar consuming click with DRAGGABLE_SUBTREE (when focus lost and gained) In-Reply-To: References: Message-ID: Hi, Thanks, and I agree it makes no sense; but it was just some behaviour I noticed (oddly enough, the same problem didn't occur with a Button which was draggable but I didn't investigate further). Anyway, I made the MenuBar draggable *initially* so the empty space to the right of it was draggable. A better solution is to just to use a HBox instead with a non-draggable MenBar and draggable spacer Region. The downside there is the previously-available resize cursor gets lost over the MenuBar part though (i.e., what we're discussing in another thread). Kind Regards, Cormac On Fri, 2 Jan 2026 at 13:05, Michael Strau? wrote: > > I've noticed this behaviour as follows with a HeaderBar stage and > MenuBar. > > > > If you make the JFX window lose focus, but still keep it visible, note > the Menu items are responding to mouse hovers. But the first click is > always ignored (i.e., no menu shown). This can be more frustrating than it > may sound, when dealing with a lot of popups and secondary window hopping, > etc. I assume this is not limited to MenuBar either. > > > > Example and code below. I will browse to Notepad to lose focus. The red > circle you see is a click, see how it requires two clicks for the menu to > appear when coming back from Notepad. Note this is not the behaviour for > "Normal Menu", a menu not inside HeaderBar. > > > You've set an interactive element (the MenuBar) to be draggable, > that's the source of problem. I don't think that it's worth supporting > the specific scenario of click activation, as you'll soon run into > even more problems (for example, you can drag away the window under an > open menu. > > Interactive draggable elements is simply not a supported > configuration. Maybe I should explicitly point this out in the > documentation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Fri Jan 2 17:53:13 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 2 Jan 2026 17:53:13 GMT Subject: RFR: 8369049: [TestBug] Update JUnit to Version 6.0.1 [v2] In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 12:32:49 GMT, Marius Hanl wrote: >> JUnit 6.0.1 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 >> https://docs.junit.org/current/release-notes/index.html#release-notes-6.0.1 >> >> 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. > > 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 three additional commits since the last revision: > > - 6.0.1 > - Merge branch 'master' of https://github.com/openjdk/jfx into junit6-upgrade > - Update to JUnit Version 6.0.0 As mentioned in thee ticket, there is no hurry to merge this. JUnit 6.1.0 will be released soon, I think we can wait for it and directly upgrade to 6.1.0. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1925#issuecomment-3705910837 From mstrauss at openjdk.org Fri Jan 2 18:47:29 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 2 Jan 2026 18:47:29 GMT Subject: RFR: 8369836: Update HeaderBar API [v11] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Unspecified HeaderDragType is behind top resize border ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/44c216bd..d0d16010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=09-10 Stats: 120 lines in 12 files changed: 67 ins; 5 del; 48 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 michaelstrau2 at gmail.com Fri Jan 2 18:56:34 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 2 Jan 2026 19:56:34 +0100 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: I think I've found a solution that should work for everyone: 1. If you just place controls in the header bar and do nothing else, you'll get a resize border on top of your controls. With this default, we the resize border takes precedence over interactive controls. 2. If you specifically set HeaderDragType.NONE on your controls, and the controls are pushed up to the edge of the header bar, you won't get a resize border on the controls. Use this if you want the entirety of your interactive controls to be clickable. The code is in the latest version of the PR. From mstrauss at openjdk.org Sat Jan 3 00:40:57 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 3 Jan 2026 00:40:57 GMT Subject: RFR: 8369836: Update HeaderBar API [v12] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/d0d16010..4ebd04d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=10-11 Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 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 michaelstrau2 at gmail.com Sat Jan 3 00:52:29 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 3 Jan 2026 01:52:29 +0100 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> <3312da0d-1d47-45dc-86af-92b59097cd35@xpipe.io> <2f4fc5fb-9d25-4f04-9606-383f260bffaf@xpipe.io> Message-ID: On the other hand, early access releases _are_ releases, and creating an installer from a jpackaged application doesn't seem far-fetched. Maybe we should version the DLLs appropriately, for example by including the build number. On Fri, Jan 2, 2026 at 3:52?AM Christopher Schnick wrote: > > Figured out the problem. We were shipping 26+ea-3 in the last version > and then bumped it to 26+ea-19. > > When distributing applications through an .msi, e.g. via jpackage, the > msi will by default only replace files if certain conditions are met > like the file version being different. > (https://learn.microsoft.com/en-gb/windows/win32/msi/replacing-existing-files) > > Since all JavaFX ea releases are marked as v26.0.0.0 when taking a look > at the properties of the shipped JavaFX .dlls, the msi installer does > not guarantee that it will upgrade the older JavaFX dlls as they both > have the same version. That way, some people might end up with the wrong > dlls after an update. I am still not sure why this only happens to some > users though. > > I don't think this is a JavaFX issue really, more of an unfortunate > default behavior of msis. From mstrauss at openjdk.org Sun Jan 4 01:45:10 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 4 Jan 2026 01:45:10 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: align Linux/Windows behavior when clicking on resize border ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/4ebd04d0..9776200a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=11-12 Stats: 74 lines in 3 files changed: 57 ins; 11 del; 6 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 jvos at openjdk.org Sun Jan 4 16:26:02 2026 From: jvos at openjdk.org (Johan Vos) Date: Sun, 4 Jan 2026 16:26:02 GMT Subject: [jfx21u] RFR: 8339335: set number of parallel jobs when building webkit Message-ID: Hi all, This pull request contains a backport of commit 4647367c from the openjdk/jfx repository. The commit being backported was authored by Johan Vos on 4 Sep 2024 and was reviewed by Andy Goryachev and Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 4647367ce4590440fbb85675055225c869502314 Changes: https://git.openjdk.org/jfx21u/pull/107/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339335 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/107.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/107/head:pull/107 PR: https://git.openjdk.org/jfx21u/pull/107 From jvos at openjdk.org Sun Jan 4 16:33:02 2026 From: jvos at openjdk.org (Johan Vos) Date: Sun, 4 Jan 2026 16:33:02 GMT Subject: [jfx17u] Integrated: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 16:22:09 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 4647367c from the openjdk/jfx repository. > > The commit being backported was authored by Johan Vos on 4 Sep 2024 and was reviewed by Andy Goryachev and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: d6a98b42 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/d6a98b42397a77cff2b55d7b5f9f7553355fbda7 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod 8339335: set number of parallel jobs when building webkit 8339505: Enable parallel compilation of native code on macOS Backport-of: 4647367ce4590440fbb85675055225c869502314 ------------- PR: https://git.openjdk.org/jfx17u/pull/244 From jvos at openjdk.org Sun Jan 4 16:34:25 2026 From: jvos at openjdk.org (Johan Vos) Date: Sun, 4 Jan 2026 16:34:25 GMT Subject: [jfx21u] Integrated: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 16:19:06 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 4647367c from the openjdk/jfx repository. > > The commit being backported was authored by Johan Vos on 4 Sep 2024 and was reviewed by Andy Goryachev and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: 8370ce3a Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/8370ce3a3465c31e2f173d8e6bceb3b730efa922 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod 8339335: set number of parallel jobs when building webkit 8339505: Enable parallel compilation of native code on macOS Backport-of: 4647367ce4590440fbb85675055225c869502314 ------------- PR: https://git.openjdk.org/jfx21u/pull/107 From jvos at openjdk.org Sun Jan 4 16:33:02 2026 From: jvos at openjdk.org (Johan Vos) Date: Sun, 4 Jan 2026 16:33:02 GMT Subject: [jfx17u] Integrated: 8339335: set number of parallel jobs when building webkit Message-ID: Hi all, This pull request contains a backport of commit 4647367c from the openjdk/jfx repository. The commit being backported was authored by Johan Vos on 4 Sep 2024 and was reviewed by Andy Goryachev and Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 4647367ce4590440fbb85675055225c869502314 Changes: https://git.openjdk.org/jfx17u/pull/244/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339335 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/244.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/244/head:pull/244 PR: https://git.openjdk.org/jfx17u/pull/244 From arapte at openjdk.org Mon Jan 5 07:39:55 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 5 Jan 2026 07:39:55 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev wrote: > Fixed two crashes: > - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. > - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. Suggesting a minor change, otherwise LGTM. modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 270: > 268: } > 269: > 270: AVFAudioEqualizer::~AVFAudioEqualizer() { Should destroy the mutex in the `~AVFAudioEqualizer()` --> `pthread_mutex_destroy(&mBandLock);` ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2008#pullrequestreview-3625724607 PR Review Comment: https://git.openjdk.org/jfx/pull/2008#discussion_r2660508538 From lkostyra at openjdk.org Mon Jan 5 14:34:56 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Jan 2026 14:34:56 GMT Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage fails to receive focus [v2] In-Reply-To: References: Message-ID: <9tkldlHZmjDy_6ZSuJbamA2pSjTj9q4nY7hthtkhu5E=.67f774d1-a081-4430-8e05-218d1ed720bc@github.com> 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 Forgot to move this one to drafts before the Christmas break. I want to come back to this one but I haven't found a reasonable solution yet, need more time to get to it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1849#issuecomment-3710678051 From lkostyra at openjdk.org Mon Jan 5 14:42:51 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 5 Jan 2026 14:42:51 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev wrote: > # Use Case > > typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: > - open MS Word or another rich text editor such as TextEdit > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > > # Problem > > typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. > > > # Solution > > - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null Took a first look at this, this looks good but I have trouble verifying this. The tests work but I also wanted to do some manual testing, I'm following the steps in the issue description using RichEditorDemo and the behavior seems the same with and without this change. Should this have any effect on our existing demos? ------------- PR Review: https://git.openjdk.org/jfx/pull/2017#pullrequestreview-3627121103 From angorya at openjdk.org Mon Jan 5 15:38:17 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 15:38:17 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property In-Reply-To: References: Message-ID: <0ZlHUhsnu9RlWG6a-p2HuEJNcmjqzBSxe4dzRkqRVbk=.5761241a-cd0c-453d-b8a0-7b72da1e0746@github.com> On Mon, 5 Jan 2026 14:39:46 GMT, Lukasz Kostyra wrote: > Should this have any effect on our existing demos? The demo is being modified on this branch - https://github.com/andy-goryachev-oracle/jfx/tree/8373936.editor In theory, you could modify an existing RTA demo by adding let's say a `CheckBox`, binding RTA's `insertStyle` property to the checkbox selected value (null / some styles). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2017#issuecomment-3710925099 From andy.goryachev at oracle.com Mon Jan 5 16:46:14 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 5 Jan 2026 16:46:14 +0000 Subject: Default event handlers In-Reply-To: References: Message-ID: Michael: Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ? Thanks, -andy From: openjfx-dev on behalf of Michael Strau? Date: Thursday, December 25, 2025 at 02:49 To: openjfx-dev Subject: Re: Default event handlers I've run into some problems while trying to make event handlers on skins only act when the event isn't consumed by user code. Consider a button that is nested in some hierarchy: scene --> root ----> button When the button receives a MOUSE_RELEASED event, it consumes the event and fires off an ACTION event. Doing that in a default handler is fine, but as as consequence, the MOUSE_RELEASED event won't be immediately consumed. Instead, it bubbles up the entire hierarchy before it is finally handled and consumed by the button in its default handler after the dispatch chain has completed. This is clearly not what we want, as it can potentially cause ancestors to act on the event, too. (By the way, this also rules out an event system where events are dispatched in prioritized capture/bubble phases.) I think what we need is quite a bit simpler. Default event handlers are still the way to go, but they shouldn't act across the entire dispatch chain. Instead, they should only act locally on a single event target: when a target receives an event, it first invokes its regular handlers. Then, if the event is still eligible for default handling, the default handlers are invoked. Skins and behaviors should always use default handlers, never regular handlers. In the example, the button would consume the MOUSE_RELEASED event in its default handler, which will prevent it from bubbling up the hierarchy. If user code adds an event handler to the button, the user handler will always be invoked first and gets to decide whether to consume the event (Event.consume()), prevent the default handler from running (Event.preventDefault()), or let it continue to flow. Using this simplified model, I've been able to switch over InputMap and ListenerHelper (and therefore almost all controls) to use default handling, and it seems to work pretty well. Here is a PR with the implementation: https://github.com/openjdk/jfx/pull/2022 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Jan 5 17:11:19 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 5 Jan 2026 18:11:19 +0100 Subject: Default event handlers In-Reply-To: References: Message-ID: Yes, the problem as described in the JBS ticket disappears when I run it with the default event handlers branch. With the new approach, skins only add default event handlers, and applications (should) only add normal event handlers. This is the separation that's necessary to resolve the control/skin order dependency. On Mon, Jan 5, 2026 at 5:46?PM Andy Goryachev wrote: > > Michael: > > Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ? > > Thanks, > -andy From andy.goryachev at oracle.com Mon Jan 5 17:16:53 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 5 Jan 2026 17:16:53 +0000 Subject: [External] : Re: Default event handlers In-Reply-To: References: Message-ID: Could you perhaps add a description to the draft PR summarizing the public API changes? Not a complete CSR, just a TL;DR. Thanks! -andy From: Michael Strau? Date: Monday, January 5, 2026 at 09:11 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: Default event handlers Yes, the problem as described in the JBS ticket disappears when I run it with the default event handlers branch. With the new approach, skins only add default event handlers, and applications (should) only add normal event handlers. This is the separation that's necessary to resolve the control/skin order dependency. On Mon, Jan 5, 2026 at 5:46?PM Andy Goryachev wrote: > > Michael: > > Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ? > > Thanks, > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jan 5 17:23:36 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 5 Jan 2026 17:23:36 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException Message-ID: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> This fixes a small issue where an NPE was always thrown on startup. ------------- Commit messages: - Remove ProperyHelper class Changes: https://git.openjdk.org/jfx/pull/2023/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374515 Stats: 41 lines in 2 files changed: 0 ins; 40 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2023.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2023/head:pull/2023 PR: https://git.openjdk.org/jfx/pull/2023 From kcr at openjdk.org Mon Jan 5 17:23:37 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jan 2026 17:23:37 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. @crschnick We _never_ reuse a JBS bug ID that is Resolved as Fixed. This PR will need a new bug. Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3711214011 From duke at openjdk.org Mon Jan 5 17:23:38 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 5 Jan 2026 17:23:38 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> On Mon, 5 Jan 2026 16:39:07 GMT, Kevin Rushforth wrote: >> This fixes a small issue where an NPE was always thrown on startup. > > @crschnick We _never_ reuse a JBS bug ID that is Resolved as Fixed. This PR will need a new bug. Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. @kevinrushforth That bug is already a new one. I don't have control over how newly opened bugs are handled in terms of state. I recently submitted a little bit more clearer instructions on how to reproduce, but I think the original instructions were clear enough as the method only has one catch block. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3711245741 From kcr at openjdk.org Mon Jan 5 17:23:39 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jan 2026 17:23:39 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> Message-ID: On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick wrote: > That bug is already a new one. I don't have control over how newly opened bugs are handled in terms of state. Ah, my mistake. I misread the state of that bug (and didn't actually look at it). I'll move it from "Incomplete" back to the "Open". One thing you will need to do is to add a Description to this PR with a short evaluation of the bug. The PR body (i.e., the Description field) must not be empty. This is obviously a bug in the (completely unnecessary) `PropertyHelper` class. Your solution of removing that obsolete class, and changing the one place it is used to directly call `Boolean.getBoolean` seems fine. A single reviewer is sufficient. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3711349057 From angorya at openjdk.org Mon Jan 5 17:33:00 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 17:33:00 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. always good to remove unnecessary code. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2023#pullrequestreview-3627773789 From kcr at openjdk.org Mon Jan 5 17:33:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jan 2026 17:33:01 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. LGTM Please allow 24 hours before integrating it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2023#pullrequestreview-3627781566 From angorya at openjdk.org Mon Jan 5 17:35:32 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 17:35:32 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 16:39:07 GMT, Kevin Rushforth wrote: > Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. isn't 8374515 the right bug id? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3711408831 From kcr at openjdk.org Mon Jan 5 17:46:22 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 5 Jan 2026 17:46:22 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 17:33:14 GMT, Andy Goryachev wrote: > > Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. > > isn't 8374515 the right bug id? Yes, it is. As I mentioned above, I misread the state of that bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3711437444 From angorya at openjdk.org Mon Jan 5 19:00:44 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 19:00:44 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v3] In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 19:04:53 GMT, Marius Hanl wrote: >> Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Fix test format > > modules/javafx.controls/src/test/java/test/javafx/scene/control/PasswordFieldTest.java line 102: > >> 100: >> 101: @Test >> 102: public void accessibleAttributeText() { > > Probably Minor, but having those 4 cases as small separate tests (2 or 4 tests) with a good test name for each is (at least IMO) a little bit more nice I think this is ok, especially if all the cases are exercised (I also like writing these kinds of extended tests). Unless there is a good reason, I'd leave this decision up to the author. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2020#discussion_r2662499802 From angorya at openjdk.org Mon Jan 5 19:29:31 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 19:29:31 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() Message-ID: Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. This is a breaking change with low impact, ok since the feature is still incubating. ------------- Commit messages: - set paragraph direction Changes: https://git.openjdk.org/jfx/pull/2021/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374347 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2021.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2021/head:pull/2021 PR: https://git.openjdk.org/jfx/pull/2021 From mstrauss at openjdk.org Mon Jan 5 22:54:57 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 5 Jan 2026 22:54:57 GMT Subject: Integrated: 8373038: Interpolator factories should follow method naming convention In-Reply-To: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com> References: <86-PY5KbI9_yE0m1-afDGczK0O7-4bSQj2wzeAhLouo=.9d0b7494-2f9b-405f-ab0b-666e762c159e@github.com> Message-ID: On Wed, 3 Dec 2025 17:08:24 GMT, Michael Strau? wrote: > The following interpolator factories don't follow the standard method naming convention: > > * `Interpolator.SPLINE(double, double, double, double)` > * `Interpolator.TANGENT(Duration, double, Duration, double)` > * `Interpolator.TANGENT(Duration, double)` > * `Interpolator.STEPS(int, StepPosition)` > > New methods named `ofSpline`, `ofTangent`, and `ofSteps` are added. The existing methods are deprecated (not for removal) in favor of the correctly-named methods. This change is in line with the new `ofLinear` method added with #1977. This pull request has now been integrated. Changeset: 79849fa6 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/79849fa6e939abbab1d92cfcb4b8c6d22f7a83c6 Stats: 138 lines in 7 files changed: 65 ins; 8 del; 65 mod 8373038: Interpolator factories should follow method naming convention Reviewed-by: angorya, kcr, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1996 From angorya at openjdk.org Mon Jan 5 23:08:06 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 5 Jan 2026 23:08:06 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) [v5] In-Reply-To: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> References: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> Message-ID: On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond wrote: >> Fix overflow menu triggering due to floating-point precision error. >> >> At 1.25 display scaling on Windows, floating-point comparison errors (e.g. 109.60000000000001 > 109.6) cause the overflow menu to appear when the lefthand value is regarded as larger than the righthand value. >> >> These should be treated as equal (and therefore not display the overflow menu). >> >> This bug can happen in both horizontal and vertical toolbar orientation. >> >> The new tests added fail without this fix, and pass with it. An existing test has been re-factored slightly to allow re-use and more flexibility in specifying the scene's root node. > > Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision: > > 8366739: remove pointless re-assignment of length looks good, tested on windows at 100%, 127%, 150%, and 175%. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2016#pullrequestreview-3628685294 From mstrauss at openjdk.org Mon Jan 5 23:14:08 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 5 Jan 2026 23:14:08 GMT Subject: RFR: 8369836: Update HeaderBar API In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:14:37 GMT, Kevin Rushforth 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\. >> >> >> 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 > >> 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. @kevinrushforth I think this PR has evolved nicely, and incorporates quite a bit of feedback we've received so far. Do you have the chance to look at the CSR in the next few days, so that I can finalize it this week? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3712415764 From duke at openjdk.org Mon Jan 5 23:38:44 2026 From: duke at openjdk.org (duke) Date: Mon, 5 Jan 2026 23:38:44 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) [v5] In-Reply-To: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> References: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> Message-ID: On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond wrote: >> Fix overflow menu triggering due to floating-point precision error. >> >> At 1.25 display scaling on Windows, floating-point comparison errors (e.g. 109.60000000000001 > 109.6) cause the overflow menu to appear when the lefthand value is regarded as larger than the righthand value. >> >> These should be treated as equal (and therefore not display the overflow menu). >> >> This bug can happen in both horizontal and vertical toolbar orientation. >> >> The new tests added fail without this fix, and pass with it. An existing test has been re-factored slightly to allow re-use and more flexibility in specifying the scene's root node. > > Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision: > > 8366739: remove pointless re-assignment of length @credmond Your change (at version 6ce13f8eaee57400a1009cc1024fce61ad840394) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3712469534 From duke at openjdk.org Mon Jan 5 23:43:15 2026 From: duke at openjdk.org (Cormac Redmond) Date: Mon, 5 Jan 2026 23:43:15 GMT Subject: Integrated: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 02:42:12 GMT, Cormac Redmond wrote: > Fix overflow menu triggering due to floating-point precision error. > > At 1.25 display scaling on Windows, floating-point comparison errors (e.g. 109.60000000000001 > 109.6) cause the overflow menu to appear when the lefthand value is regarded as larger than the righthand value. > > These should be treated as equal (and therefore not display the overflow menu). > > This bug can happen in both horizontal and vertical toolbar orientation. > > The new tests added fail without this fix, and pass with it. An existing test has been re-factored slightly to allow re-use and more flexibility in specifying the scene's root node. This pull request has now been integrated. Changeset: 5b97edf6 Author: Cormac Redmond Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/5b97edf636a5e1f2db6c8f5484df01aef6009d29 Stats: 81 lines in 2 files changed: 46 ins; 10 del; 25 mod 8366739: ToolBar: overflow menu with fractional scale (2) Reviewed-by: jhendrikx, angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/2016 From credmond at certak.com Mon Jan 5 23:48:32 2026 From: credmond at certak.com (Cormac Redmond) Date: Mon, 5 Jan 2026 23:48:32 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi Michael -- thanks for this. Seems like a good default. I haven't been able to test yet. I will get back to you tomorrow! On Fri 2 Jan 2026, 18:56 Michael Strau?, wrote: > I think I've found a solution that should work for everyone: > > 1. If you just place controls in the header bar and do nothing else, > you'll get a resize border on top of your controls. With this default, > we the resize border takes precedence over interactive controls. > > 2. If you specifically set HeaderDragType.NONE on your controls, and > the controls are pushed up to the edge of the header bar, you won't > get a resize border on the controls. Use this if you want the entirety > of your interactive controls to be clickable. > > The code is in the latest version of the PR. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jan 5 23:53:51 2026 From: duke at openjdk.org (Cormac Redmond) Date: Mon, 5 Jan 2026 23:53:51 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 18:08:26 GMT, Andy Goryachev wrote: >>> > @credmond would you like to create a login in JBS and own the ticket https://bugs.openjdk.org/browse/JDK-8366739 so your fix gets properly credited? >>> >>> Sure @andy-goryachev-oracle, would be good for future also. I don't see any way to request that -- do you need to do something on your side? >> >> Andy was mistaken. There isn't a way to request this. JBS accounts are tied to having an OpenJDK ID, which means becoming an [Author](https://openjdk.org/bylaws#author) in an OpenJDK Project. >> >> The JBS bug ID question can be assigned to the sponsor of the PR. You will be listed in `git` as having authored the PR, using the name and email address from the HEAD commit of your PR branch. > >> becoming an [Author](https://openjdk.org/bylaws#author) > > also good :-) Thanks, @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3712501962 From almatvee at openjdk.org Tue Jan 6 00:00:51 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jan 2026 00:00:51 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] In-Reply-To: References: Message-ID: > Fixed two crashes: > - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. > - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2008/files - new: https://git.openjdk.org/jfx/pull/2008/files/5fa212a5..920c5e7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2008&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2008&range=00-01 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2008.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2008/head:pull/2008 PR: https://git.openjdk.org/jfx/pull/2008 From almatvee at openjdk.org Tue Jan 6 00:00:53 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jan 2026 00:00:53 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 In-Reply-To: References: Message-ID: <8nEXguapP8wJyt1gyLm_iJ893fV1j0G61oXuQsNPJF0=.d5b26768-04fa-4a02-bcf8-24d28ed36b61@github.com> On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev wrote: > Fixed two crashes: > - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. > - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] - Added missing `pthread_mutex_destroy` to `AVFAudioSpectrumUnit` and `AVFAudioEqualizer`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2008#issuecomment-3712513869 From angorya at openjdk.org Tue Jan 6 00:03:58 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 00:03:58 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev wrote: >> Fixed two crashes: >> - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. >> - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 289: > 287: mEQBands.clear(); > 288: > 289: pthread_mutex_destroy(&mBandLock); do we need a conditional here or it's always ok even if the mBandLock was never used? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2008#discussion_r2663140214 From almatvee at openjdk.org Tue Jan 6 00:15:05 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 6 Jan 2026 00:15:05 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:01:06 GMT, Andy Goryachev wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] > > modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 289: > >> 287: mEQBands.clear(); >> 288: >> 289: pthread_mutex_destroy(&mBandLock); > > do we need a conditional here or it's always ok even if the mBandLock was never used? We always initialize `mBandLock` in constructor, so we need to call `pthread_mutex_destroy`. It should be called if `pthread_mutex_init` was called. Does not matter if we locked/unlocked mutex. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2008#discussion_r2663153595 From arapte at openjdk.org Tue Jan 6 07:45:03 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 6 Jan 2026 07:45:03 GMT Subject: RFR: 8374573: Update copyright header for files modified in 2025 Message-ID: As we enter year 2026, update copyright year in files updated in the year 2025. ------------- Commit messages: - copy-year-2025 Changes: https://git.openjdk.org/jfx/pull/2024/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374573 Stats: 50 lines in 50 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.org/jfx/pull/2024.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2024/head:pull/2024 PR: https://git.openjdk.org/jfx/pull/2024 From jhendrikx at openjdk.org Tue Jan 6 07:50:58 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 07:50:58 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx wrote: >> This fixes a long standing bug with `GridPane` where unmanaged nodes would still result in gaps being added between rows/columns even though nothing is rendered there. Take the following grid where dashes and pipes represent the vgaps and hgaps: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |1 |C|||D| >> | |-|||-| >> |2 |E|||F| >> >> Now, when both C and D are set to unmanaged (and invisible) the grid will **still** render the gaps: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |1 ||||| >> | |-|||-| >> |2 |E|||F| >> >> Instead it should collapse the gap between row 0 and 2: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |2 |E|||F| >> >> There are at least two relevant issues in JBS: >> - A request to let the user show and hide rows and columns: https://bugs.openjdk.org/browse/JDK-8136901 >> - This can now be done by setting the relevant row/columns items to unmanaged without having to restructure the grid (assuming the complaint was that otherwise there'd be visible extra gaps for each hidden row) >> - A request for another mode to skip gaps when entire rows/columns are unmanaged: https://bugs.openjdk.org/browse/JDK-8092379 >> - This should not be a mode, but the standard, as unmanaged nodes should not affect the outcome of the grid layout >> >> Screenshots >> >> Simple application which can hide row 3: >> >> image >> >> Correct behavior when row 3 is hidden: >> >> image >> >> Behavior before this fix (note the double gap **and** extra grid line): >> >> image > > John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > When all nodes starting in a row or column are unmanaged, skip gap Could I get a 2nd reviewer on this one? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1990#issuecomment-3713550113 From jhendrikx at openjdk.org Tue Jan 6 07:51:00 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 07:51:00 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: Message-ID: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> On Mon, 1 Dec 2025 22:36:12 GMT, Andy Goryachev wrote: >> Yeah, could remove, I just made the change because it was giving a raw type warning. > > I turned the raw warnings off, the project has thousands of those... You can put them on INFO to avoid introducing new problems (and seeing what can be fixed when you are nearby). Even though raw warnings are usually harmless, there are instances where code thinks the type is X when it is actually Y; fixing raw warnings problems will uncover those. We should definitely not be using more raw code, as that's basically reverting to Java 1.4 days. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2663974372 From jhendrikx at openjdk.org Tue Jan 6 07:54:33 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 07:54:33 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:24:32 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more debug output > > Note: I am using the latest standalone monkey tester https://github.com/andy-goryachev-oracle/MonkeyTest but a similar issue is present in the one that's currently in the main repo. @andy-goryachev-oracle Could you have another look? I think this fixes all issues, and we may be able to proceed with #1945 then. If you agree, I'll remove the debug lines so it can be reviewed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3713557388 From mhanl at openjdk.org Tue Jan 6 10:45:14 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Jan 2026 10:45:14 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. Good to remove these pretty much unused code. And a good improvement, as creating an exception (which will then record the stacktrace) is always costly. And as you wrote, annoying when listening on NPEs when debugging. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/2023#pullrequestreview-3630413358 From kcr at openjdk.org Tue Jan 6 13:44:21 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 13:44:21 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> Message-ID: On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick wrote: >> @crschnick We _never_ reuse a JBS bug ID that is Resolved as Fixed. This PR will need a new bug. Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. > > @kevinrushforth That bug is already a new one. I don't have control over how newly opened bugs are handled in terms of state. > > I recently submitted a little bit more clearer instructions on how to reproduce, but I think the original instructions were clear enough as the method only has one catch block. @crschnick When ready, integrate this PR by entering `/integrate` in a PR comment (by itself). Andy or I will sponsor it for you. > @crschnick When ready, integrate this PR by entering `/integrate` in a PR comment (by itself). Andy or I will sponsor it for you. ~~In about 4 hours, that is (it hasn't quite been 24 hours).~~ ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3714733622 PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3714736081 From kcr at openjdk.org Tue Jan 6 13:44:23 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 13:44:23 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. It's close enough to 24 hours and has three approvals, so it's fine. I'll sponsor it now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3714739086 From duke at openjdk.org Tue Jan 6 13:44:23 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 6 Jan 2026 13:44:23 GMT Subject: Integrated: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> Message-ID: On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick wrote: > This fixes a small issue where an NPE was always thrown on startup. This pull request has now been integrated. Changeset: 3561d522 Author: Christopher Schnick Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/3561d522ad1e40ac330a07958ad00eda3a24aa62 Stats: 41 lines in 2 files changed: 0 ins; 40 del; 1 mod 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException Reviewed-by: angorya, kcr, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/2023 From kcr at openjdk.org Tue Jan 6 13:47:23 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 13:47:23 GMT Subject: RFR: 8374573: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 07:38:07 GMT, Ambarish Rapte wrote: > As we enter year 2026, update copyright year in files updated in the year 2025. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2024#pullrequestreview-3630951074 From kcr at openjdk.org Tue Jan 6 13:53:57 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 13:53:57 GMT Subject: RFR: 8374515: javafx.scene.PropertyHelper causes uncessary silent NullPointerException In-Reply-To: <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com> <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com> Message-ID: On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick wrote: >> @crschnick We _never_ reuse a JBS bug ID that is Resolved as Fixed. This PR will need a new bug. Please remove the bug ID (8374515) from the title of this PR and later replace it with the new bug ID. > > @kevinrushforth That bug is already a new one. I don't have control over how newly opened bugs are handled in terms of state. > > I recently submitted a little bit more clearer instructions on how to reproduce, but I think the original instructions were clear enough as the method only has one catch block. @crschnick I only just noticed that you didn't have GitHub Actions enabled for your personal fork of the jfx repo. Fortunately, this is a trivial enough fix that there will be no problems (I built and tested it myself, so I know it works). If you plan to submit any more PRs, please enable GitHub Actions workflows for your personal fork. @kevinrushforth @andy-goryachev-oracle @Maran23 We should let this be a reminder to us (especially to me!) to check that a GHA test build was run before approving a PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2023#issuecomment-3714767584 From kcr at openjdk.org Tue Jan 6 13:53:58 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 13:53:58 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 23:50:45 GMT, Cormac Redmond wrote: >>> becoming an [Author](https://openjdk.org/bylaws#author) >> >> also good :-) > > Thanks, @andy-goryachev-oracle @credmond I noticed after this PR was integrated that you didn't have GitHub Actions enabled for your personal fork of the jfx repo. Fortunately, our CI build that was triggered by the integration passes. If you plan to submit any more PRs, please enable GitHub Actions workflows for your personal fork. @andy-goryachev-oracle @hjohn @Maran23 We should let this be a reminder to us to check that a GHA test build was run before approving a PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3714777645 From mhanl at openjdk.org Tue Jan 6 14:12:20 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 6 Jan 2026 14:12:20 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 18:08:26 GMT, Andy Goryachev wrote: >>> > @credmond would you like to create a login in JBS and own the ticket https://bugs.openjdk.org/browse/JDK-8366739 so your fix gets properly credited? >>> >>> Sure @andy-goryachev-oracle, would be good for future also. I don't see any way to request that -- do you need to do something on your side? >> >> Andy was mistaken. There isn't a way to request this. JBS accounts are tied to having an OpenJDK ID, which means becoming an [Author](https://openjdk.org/bylaws#author) in an OpenJDK Project. >> >> The JBS bug ID question can be assigned to the sponsor of the PR. You will be listed in `git` as having authored the PR, using the name and email address from the HEAD commit of your PR branch. > >> becoming an [Author](https://openjdk.org/bylaws#author) > > also good :-) > @andy-goryachev-oracle @hjohn @Maran23 We should let this be a reminder to us to check that a GHA test build was run before approving a PR. Thanks for the ping, yes that makes sense, we should all have an eye on that. I was assuming that this is always turned on by default. Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3714833896 From kcr at openjdk.org Tue Jan 6 14:35:38 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 14:35:38 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 14:08:12 GMT, Marius Hanl wrote: > Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. Yes, that is the easiest way to tell (and is how I eventually noticed). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3714927531 From duke at openjdk.org Tue Jan 6 14:41:47 2026 From: duke at openjdk.org (Cormac Redmond) Date: Tue, 6 Jan 2026 14:41:47 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 23:50:45 GMT, Cormac Redmond wrote: >>> becoming an [Author](https://openjdk.org/bylaws#author) >> >> also good :-) > > Thanks, @andy-goryachev-oracle > @credmond I noticed after this PR was integrated that you didn't have GitHub Actions enabled for your personal fork of the jfx repo. Fortunately, our CI build that was triggered by the integration passes. If you plan to submit any more PRs, please enable GitHub Actions workflows for your personal fork. > > @andy-goryachev-oracle @hjohn @Maran23 We should let this be a reminder to us to check that a GHA test build was run before approving a PR. Will do next time, @kevinrushforth. It was indeed disabled: image. I didn't realise this was a requirement, or that it would even work E.g., often forked repo workflows fail due to missing secrets/variables or self-hosted runners, etc. It might be worth mentioning this requirement here: - https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md Running the GHA invoked tests is mentioned here https://github.com/openjdk/jfx/blob/master/README-code-reviews.md: > Make sure that the PR has executed the GitHub Actions (GHA) tests; if they aren't being run, ask the PR author to enable GHA workflows; ...but that's aimed for reviewers, not contributors, and could be missed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3714952038 From jhendrikx at openjdk.org Tue Jan 6 15:11:24 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 15:11:24 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) [v5] In-Reply-To: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> References: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> Message-ID: <7eOGBmRwitKBKHM6mBcsxKW0vWmy5KpJ0zjXD1XiR78=.642cca4b-b4d2-4cd9-8ed2-d1fec545f0f8@github.com> On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond wrote: >> Fix overflow menu triggering due to floating-point precision error. >> >> At 1.25 display scaling on Windows, floating-point comparison errors (e.g. 109.60000000000001 > 109.6) cause the overflow menu to appear when the lefthand value is regarded as larger than the righthand value. >> >> These should be treated as equal (and therefore not display the overflow menu). >> >> This bug can happen in both horizontal and vertical toolbar orientation. >> >> The new tests added fail without this fix, and pass with it. An existing test has been re-factored slightly to allow re-use and more flexibility in specifying the scene's root node. > > Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision: > > 8366739: remove pointless re-assignment of length I didn't realize that was even possible. I can't see it anymore now that the build was missing, as it looks like any other integrated PR. I'll keep a closer eye on it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3715051224 From jhendrikx at openjdk.org Tue Jan 6 15:11:26 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 15:11:26 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 14:31:53 GMT, Kevin Rushforth wrote: >>> @andy-goryachev-oracle @hjohn @Maran23 We should let this be a reminder to us to check that a GHA test build was run before approving a PR. >> >> Thanks for the ping, yes that makes sense, we should all have an eye on that. >> I was assuming that this is always turned on by default. Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. > >> Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. > > Yes, that is the easiest way to tell (and is how I eventually noticed). @kevinrushforth maybe the bot can add another check for that or label? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3715057767 From lkostyra at openjdk.org Tue Jan 6 15:28:56 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 6 Jan 2026 15:28:56 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev wrote: > # Use Case > > typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: > - open MS Word or another rich text editor such as TextEdit > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > > # Problem > > typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. > > > # Solution > > - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null LGTM ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2017#pullrequestreview-3631331650 From angorya at openjdk.org Tue Jan 6 15:29:31 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 15:29:31 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v7] In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx wrote: >> When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene. It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen. After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once). >> >> The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off. As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale. >> >> When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen). However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was. >> >> To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size. Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Avoid NaN's when determining screen yes, I was planning to take a look at this today ------------- PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3715125144 From angorya at openjdk.org Tue Jan 6 15:33:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 15:33:38 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> References: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> Message-ID: On Tue, 6 Jan 2026 07:46:54 GMT, John Hendrikx wrote: >> I turned the raw warnings off, the project has thousands of those... > > You can put them on INFO to avoid introducing new problems (and seeing what can be fixed when you are nearby). Even though raw warnings are usually harmless, there are instances where code thinks the type is X when it is actually Y; fixing raw warnings problems will uncover those. We should definitely not be using more raw code, as that's basically reverting to Java 1.4 days. I might disagree here: if we are not planning to fix these thousands of warnings, the warning should be disabled. I do want to point you to a problem (unrelated to this PR) - if you try to edit CssParser (a simple whitespace change for example), you'll always get these in Eclipse, quite annoying: Description Resource Location Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3029 Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3219 Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3272 Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3287 Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3612 Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3656 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2665318257 From kcr at openjdk.org Tue Jan 6 15:48:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 15:48:01 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: Message-ID: <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com> On Tue, 6 Jan 2026 14:31:53 GMT, Kevin Rushforth wrote: >>> @andy-goryachev-oracle @hjohn @Maran23 We should let this be a reminder to us to check that a GHA test build was run before approving a PR. >> >> Thanks for the ping, yes that makes sense, we should all have an eye on that. >> I was assuming that this is always turned on by default. Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. > >> Note for all others: The 'Checks' Tab always shows a 1 if GHA is not enabled (jcheck) and a 6 if it is. > > Yes, that is the easiest way to tell (and is how I eventually noticed). > @kevinrushforth maybe the bot can add another check for that or label? A check that warns if GHA is not enabled seems like a reasonable idea. I'll file an RFE for the Skara bot, although I don't know how soon such a check might be done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3715199887 From andy.goryachev at oracle.com Tue Jan 6 16:16:34 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 6 Jan 2026 16:16:34 +0000 Subject: Happy New Year Message-ID: Happy New Year everyone! Just a quick reminder to update your code templates and copyright year to 2026. Thanks, -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 6 16:17:04 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 16:17:04 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com> References: <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com> Message-ID: On Tue, 6 Jan 2026 15:43:59 GMT, Kevin Rushforth wrote: > A check that warns if GHA is not enabled seems like a reasonable idea. I'll file an RFE for the Skara bot this seems to me the most logical place. In the absence of that, we should make it a part of OCA checklist maybe. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3715312313 From fthevene at redhat.com Tue Jan 6 16:23:53 2026 From: fthevene at redhat.com (Frederic Thevenet) Date: Tue, 6 Jan 2026 17:23:53 +0100 Subject: Proposal: make JavaFX cooperate better with Flatpak sand-boxing on Linux Message-ID: Hi, I would like to discuss a change to the native implementation for CommonDialogs::showFileChooser/showFolderChooser in the GTK back-end, with the ultimate goal of making JavaFX based application work better when packaged as Flatpak[0] under Linux. Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environnement to the strict minimum, including access to the network, HW devices or the host file system. It provides a specific set of APIs, known as "XDG Desktop Portal "[1] to allow applications to only access resources the end user has specifically requested, for example a specific file, and in order to fully take advantage of Flatpak's containment feature, the guest application needs to be aware of these API; which is not the case for Java/JavaFX based applications. Fortunately, some level of support for XDG Desktop Portal is baked into GTK3 which should be easy to surface so that JavaFX can benefit from it in a transparent way. One such opportunity is the e File Chooser portal, wich make apps use the file picker dialog native to the desktop environment they?re running on, and dynamically grants permissions to the host file system to sandboxed apps, on a strictly need-to-access basis (i.e. the application is granted access only the files picked by the user using the file chooser dialog, transparently). In order to let JavaFX based apps opt into this feature, we need to replace explicit use of GtkFileChooserDialog[2] with GtkFileChooserNative[3], which is only a small change, and should completely transparent when an app is run normally, outside of a sandbox since the gtk glass implementation is only used on Linux anyway. I have prototyped it as a draft PR[4] and as you'll see, the changes are minimal. There are other aspects of the sandboxing that currently aren't supported well by Java/JavaFX applications and that this won't solve, such as the fact the? java.nio.file APIs will remain unaware of the sandbox and so will refer to the files picked by the FileChooser using a path that is opaque for the end user (e.g. "/run/user/1000/doc/adda6d11f/foo.bar" instead of "~/Downloads/foo.bar"), but this is a first step, that I believe still has much value and no obvious drawback, and I would very much like to see it considered for inclusion. Thanks! [0] https://docs.flatpak.org/en/latest/introduction.html [1] https://flatpak.github.io/xdg-desktop-portal/docs/ [2] https://docs.gtk.org/gtk3/class.FileChooserNative.html [3] https://docs.gtk.org/gtk3/class.FileChooserDialog.html [4] https://github.com/openjdk/jfx/pull/2025 -- Frederic Thevenet Senior Software Engineer - OpenJDK Red Hat France BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 From angorya at openjdk.org Tue Jan 6 16:29:21 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 16:29:21 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev wrote: >> Fixed two crashes: >> - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. >> - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2008#pullrequestreview-3631571884 From kcr at openjdk.org Tue Jan 6 16:45:07 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 16:45:07 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) In-Reply-To: References: <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com> Message-ID: On Tue, 6 Jan 2026 16:12:56 GMT, Andy Goryachev wrote: > In the absence of that, we should make it a part of OCA checklist maybe. This has nothing to do with the OCA. We might update `CONTRIBUTING.md` to mention it, though. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3715423872 From angorya at openjdk.org Tue Jan 6 17:08:33 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 17:08:33 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v2] In-Reply-To: References: Message-ID: > # Use Case > > typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: > - open MS Word or another rich text editor such as TextEdit > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > > # Problem > > typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. > > > # Solution > > - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null 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 seven additional commits since the last revision: - 2026 - Merge branch 'master' into 8374035.insert.styles - test - 26 - Merge branch 'master' into 8374035.insert.styles - Merge branch 'master' into 8374035.insert.styles - insert styles ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2017/files - new: https://git.openjdk.org/jfx/pull/2017/files/1bd80393..67066b6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2017&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2017&range=00-01 Stats: 278 lines in 15 files changed: 119 ins; 60 del; 99 mod Patch: https://git.openjdk.org/jfx/pull/2017.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2017/head:pull/2017 PR: https://git.openjdk.org/jfx/pull/2017 From angorya at openjdk.org Tue Jan 6 17:22:51 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 17:22:51 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: > Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. > > This is a breaking change with low impact, ok since the feature is still incubating. 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: - 2026 - Merge branch 'master' into 8374347.paragraph.direction - set paragraph direction ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2021/files - new: https://git.openjdk.org/jfx/pull/2021/files/c14d6951..0f0bb8a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2021&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2021&range=00-01 Stats: 276 lines in 13 files changed: 119 ins; 60 del; 97 mod Patch: https://git.openjdk.org/jfx/pull/2021.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2021/head:pull/2021 PR: https://git.openjdk.org/jfx/pull/2021 From kcr at openjdk.org Tue Jan 6 17:29:49 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 17:29:49 GMT Subject: RFR: 8269630: Bad clipboard data causes JVM to crash [v2] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra wrote: >> This commit fixes the JVM crash caused by bad Clipboard data on Linux. >> >> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard. >> >> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV. >> >> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine. >> >> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090). > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review: Move jstring cast The code changes look good. I verified on Ubuntu 24.04 that the test program attached to JBS crashes without the fix and works with the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1999#pullrequestreview-3631799700 From fthevene at redhat.com Tue Jan 6 18:04:25 2026 From: fthevene at redhat.com (Frederic Thevenet) Date: Tue, 6 Jan 2026 19:04:25 +0100 Subject: Proposal: make JavaFX cooperate better with Flatpak sand-boxing on Linux In-Reply-To: References: Message-ID: I have created JDK-8374630 to track this. Thanks, Frederic [0] https://bugs.openjdk.org/browse/JDK-8374630 On 1/6/26 5:23 PM, Frederic Thevenet wrote: > Hi, > > I would like to discuss a change to the native implementation for > CommonDialogs::showFileChooser/showFolderChooser in the GTK back-end, > with the ultimate goal of making JavaFX based application work better > when packaged as Flatpak[0] under Linux. > > Flatpak is a framework for distributing desktop applications across > various Linux distributions, that runs each application into its own > sandbox to limit its access to the host environnement to the strict > minimum, including access to the network, HW devices or the host file > system. > It provides a specific set of APIs, known as "XDG Desktop Portal "[1] > to allow applications to only access resources the end user has > specifically requested, for example a specific file, and in order to > fully take advantage of Flatpak's containment feature, the guest > application needs to be aware of these API; which is not the case for > Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked > into GTK3 which should be easy to surface so that JavaFX can benefit > from it in a transparent way. > > One such opportunity is the e File Chooser portal, wich make apps use > the file picker dialog native to the desktop environment they?re > running on, and dynamically grants permissions to the host file system > to sandboxed apps, on a strictly need-to-access basis (i.e. the > application is granted access only the files picked by the user using > the file chooser dialog, transparently). > In order to let JavaFX based apps opt into this feature, we need to > replace explicit use of GtkFileChooserDialog[2] with > GtkFileChooserNative[3], which is only a small change, and should > completely transparent when an app is run normally, outside of a > sandbox since the gtk glass implementation is only used on Linux > anyway. I have prototyped it as a draft PR[4] and as you'll see, the > changes are minimal. > > There are other aspects of the sandboxing that currently aren't > supported well by Java/JavaFX applications and that this won't solve, > such as the fact the? java.nio.file APIs will remain unaware of the > sandbox and so will refer to the files picked by the FileChooser using > a path that is opaque for the end user (e.g. > "/run/user/1000/doc/adda6d11f/foo.bar" instead of > "~/Downloads/foo.bar"), but this is a first step, that I believe still > has much value and no obvious drawback, and I would very much like to > see it considered for inclusion. > > Thanks! > > [0] https://docs.flatpak.org/en/latest/introduction.html > [1] https://flatpak.github.io/xdg-desktop-portal/docs/ > [2] https://docs.gtk.org/gtk3/class.FileChooserNative.html > [3] https://docs.gtk.org/gtk3/class.FileChooserDialog.html > [4] https://github.com/openjdk/jfx/pull/2025 > -- Frederic Thevenet Senior Software Engineer - OpenJDK Red Hat France BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 From angorya at openjdk.org Tue Jan 6 18:04:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 18:04:47 GMT Subject: RFR: 8371070: RichParagraph enhancements [v9] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 23:29:19 GMT, Andy Goryachev wrote: >> This PR addresses the user feedback: >> >> In RichParagraph you have a note to make getSegments() public. It would be helpful if it was. >> >> >> The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch. >> >> This is done in two parts: >> >> 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method >> >> >> protected RichParagraph.Builder prepareParagraph(int index) >> >> >> 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes: >> >> - getSegmentCount() >> - getSegment(int index) >> >> NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - prepare paragraph > - Merge branch 'master' into 8371070.enhance > - javadoc > - cleanup > - Merge branch 'master' into 8366198.rbuilder > - rich paragraph builder api > - Merge branch 'master' into 8371070.enhance > - npe > - merge > - Merge branch 'master' into 8371070.enhance > - ... and 4 more: https://git.openjdk.org/jfx/compare/b39e1faa...dd3ec196 Could I get a second reviewer for this please? Maybe @Ziad-Mid or @lukostyra ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1966#issuecomment-3715726851 From mfox at openjdk.org Tue Jan 6 18:49:07 2026 From: mfox at openjdk.org (Martin Fox) Date: Tue, 6 Jan 2026 18:49:07 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v7] In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx wrote: >> When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene. It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen. After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once). >> >> The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off. As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale. >> >> When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen). However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was. >> >> To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size. Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Avoid NaN's when determining screen FWIW this can't be tested on Linux at the moment. It's possible to set up a system with multiple monitors each with a different scale but due to limitations in the GTK3 API we have to choose between supporting fractional scaling or per-monitor scaling. Currently we favor fractional and so we use the same scaling factor across all monitors. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3715876249 From kcr at openjdk.org Tue Jan 6 19:37:35 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 19:37:35 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v2] In-Reply-To: References: Message-ID: <-f5-W7lVg8C9WKwriArrgg9zgZcbBAC5YdxLzIF-Gs4=.0e1cb86d-a849-4ce2-bc27-676dc9d0ce90@github.com> On Tue, 6 Jan 2026 17:08:33 GMT, Andy Goryachev wrote: >> # Use Case >> >> typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: >> - open MS Word or another rich text editor such as TextEdit >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. >> >> >> # Problem >> >> typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. >> >> >> # Solution >> >> - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null > > 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 seven additional commits since the last revision: > > - 2026 > - Merge branch 'master' into 8374035.insert.styles > - test > - 26 > - Merge branch 'master' into 8374035.insert.styles > - Merge branch 'master' into 8374035.insert.styles > - insert styles The new API looks good. I left a comment about the docs (and also a question about the new test) inline. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 600: > 598: /** > 599: * Specifies the styles to be in effect for the characters to be inserted via user input. > 600: * The value can be null. Can you document the behavior when this is null? Looking at the implementation, I think it takes the style at the caret position, but would be helpful to specify (also say whether there is a different depending on whether the caret is leading or trailing). modules/jfx.incubator.richtext/src/test/java/test/jfx/incubator/scene/control/richtext/RichTextAreaTest.java line 586: > 584: assertEquals(BOLD, control.getActiveStyleAttributeMap()); > 585: control.select(TextPos.ofLeading(0, 6)); > 586: assertEquals(ITALIC, control.getActiveStyleAttributeMap()); Maybe also test that setting it to `null` does what you expect (uses the style at the cursor I presume)? ------------- PR Review: https://git.openjdk.org/jfx/pull/2017#pullrequestreview-3632188693 PR Review Comment: https://git.openjdk.org/jfx/pull/2017#discussion_r2666027494 PR Review Comment: https://git.openjdk.org/jfx/pull/2017#discussion_r2666042191 From jhendrikx at openjdk.org Tue Jan 6 20:10:22 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 20:10:22 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> Message-ID: On Tue, 6 Jan 2026 15:29:44 GMT, Andy Goryachev wrote: >> You can put them on INFO to avoid introducing new problems (and seeing what can be fixed when you are nearby). Even though raw warnings are usually harmless, there are instances where code thinks the type is X when it is actually Y; fixing raw warnings problems will uncover those. We should definitely not be using more raw code, as that's basically reverting to Java 1.4 days. > > I might disagree here: if we are not planning to fix these thousands of warnings, the warning should be disabled. > > I do want to point you to a problem (unrelated to this PR) - if you try to edit CssParser (a simple whitespace change for example), you'll always get these in Eclipse, quite annoying: > > > Description Resource Location > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3029 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3219 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3272 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3287 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3612 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3656 Yeah, it is just a difference of opinion in the ECJ compiler and javac. It can probably be written slightly differently so it compiles properly under both. Also, I did fix a lot of those, but that PR died. Fixing ParsedValue however is IMHO a waste; that thing should never have had generic arguments in the first place; it is a classic example where adding generics costs more than it benefits. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2666145064 From angorya at openjdk.org Tue Jan 6 20:14:57 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 20:14:57 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> Message-ID: On Tue, 6 Jan 2026 20:08:08 GMT, John Hendrikx wrote: >> I might disagree here: if we are not planning to fix these thousands of warnings, the warning should be disabled. >> >> I do want to point you to a problem (unrelated to this PR) - if you try to edit CssParser (a simple whitespace change for example), you'll always get these in Eclipse, quite annoying: >> >> >> Description Resource Location >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3029 >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3219 >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3272 >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3287 >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3612 >> Cannot infer type arguments for ParsedValueImpl<> CssParser.java line 3656 > > Yeah, it is just a difference of opinion in the ECJ compiler and javac. It can probably be written slightly differently so it compiles properly under both. > > Also, I did fix a lot of those, but that PR died. Fixing ParsedValue however is IMHO a waste; that thing should never have had generic arguments in the first place; it is a classic example where adding generics costs more than it benefits. yeah. it just bothers me that before it was quietly ignored and now any time I touch the file it gives me a bunch of errors. we could complain to Eclipse folks or just fix it ourselves... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2666153371 From jhendrikx at openjdk.org Tue Jan 6 20:21:01 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 6 Jan 2026 20:21:01 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com> Message-ID: On Tue, 6 Jan 2026 20:11:16 GMT, Andy Goryachev wrote: >> Yeah, it is just a difference of opinion in the ECJ compiler and javac. It can probably be written slightly differently so it compiles properly under both. >> >> Also, I did fix a lot of those, but that PR died. Fixing ParsedValue however is IMHO a waste; that thing should never have had generic arguments in the first place; it is a classic example where adding generics costs more than it benefits. > > yeah. it just bothers me that before it was quietly ignored and now any time I touch the file it gives me a bunch of errors. we could complain to Eclipse folks or just fix it ourselves... Yeah, often though the answer will be that it confirms to the specification, and that the specification is not tight enough in some areas, resulting in slight differences between ecj/javac. I've seen it a bunch of times (often when I join a large project that has been developed exclusively in IntelliJ for a while, which only uses javac) but there's always an easy work around. I can take a look; if I can isolate the issue, I may even file a bug report for the compiler. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1990#discussion_r2666170134 From kcr at openjdk.org Tue Jan 6 20:29:08 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 20:29:08 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: <4h0v5AQ6exkKXe8BEJiJ5PcFOPVtj23z965kNPhyRZ0=.7e0b798a-44aa-4f4f-9e2a-c1737599ed75@github.com> On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev wrote: >> Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. >> >> This is a breaking change with low impact, ok since the feature is still incubating. > > 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: > > - 2026 > - Merge branch 'master' into 8374347.paragraph.direction > - set paragraph direction The API change looks good. I see that there is no caller of this method. Is adding a test for this already covered by one of the existing test bugs? If not, please file an issue or update an existing one to cover the addition of such a test. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2021#pullrequestreview-3632376274 From angorya at openjdk.org Tue Jan 6 20:46:53 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 20:46:53 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev wrote: >> Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. >> >> This is a breaking change with low impact, ok since the feature is still incubating. > > 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: > > - 2026 > - Merge branch 'master' into 8374347.paragraph.direction > - set paragraph direction @Ziad-Mid or @lukostyra could you be the second reviewer please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2021#issuecomment-3716269240 From angorya at openjdk.org Tue Jan 6 20:46:50 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 20:46:50 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: <4h0v5AQ6exkKXe8BEJiJ5PcFOPVtj23z965kNPhyRZ0=.7e0b798a-44aa-4f4f-9e2a-c1737599ed75@github.com> References: <4h0v5AQ6exkKXe8BEJiJ5PcFOPVtj23z965kNPhyRZ0=.7e0b798a-44aa-4f4f-9e2a-c1737599ed75@github.com> Message-ID: On Tue, 6 Jan 2026 20:25:05 GMT, Kevin Rushforth wrote: > If not, please file an issue or update an existing one to cover the addition of such a test. good point! created https://bugs.openjdk.org/browse/JDK-8374640 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2021#issuecomment-3716267741 From credmond at certak.com Tue Jan 6 21:07:36 2026 From: credmond at certak.com (Cormac Redmond) Date: Tue, 6 Jan 2026 21:07:36 +0000 Subject: HeaderBar non-draggable window issue In-Reply-To: References: Message-ID: Hi Michael, Tested this, appears to be working very well from my end... Thanks, let's hope it makes it to master :) ... Kind Regards, Cormac On Mon, 5 Jan 2026 at 23:48, Cormac Redmond wrote: > Hi Michael -- thanks for this. Seems like a good default. > > I haven't been able to test yet. I will get back to you tomorrow! > > On Fri 2 Jan 2026, 18:56 Michael Strau?, wrote: > >> I think I've found a solution that should work for everyone: >> >> 1. If you just place controls in the header bar and do nothing else, >> you'll get a resize border on top of your controls. With this default, >> we the resize border takes precedence over interactive controls. >> >> 2. If you specifically set HeaderDragType.NONE on your controls, and >> the controls are pushed up to the edge of the header bar, you won't >> get a resize border on the controls. Use this if you want the entirety >> of your interactive controls to be clickable. >> >> The code is in the latest version of the PR. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 6 21:07:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 21:07:38 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v3] In-Reply-To: References: Message-ID: > # Use Case > > typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: > - open MS Word or another rich text editor such as TextEdit > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > > # Problem > > typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. > > > # Solution > > - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null 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/2017/files - new: https://git.openjdk.org/jfx/pull/2017/files/67066b6e..ff264fc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2017&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2017&range=01-02 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2017.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2017/head:pull/2017 PR: https://git.openjdk.org/jfx/pull/2017 From angorya at openjdk.org Tue Jan 6 21:07:40 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 21:07:40 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v2] In-Reply-To: <-f5-W7lVg8C9WKwriArrgg9zgZcbBAC5YdxLzIF-Gs4=.0e1cb86d-a849-4ce2-bc27-676dc9d0ce90@github.com> References: <-f5-W7lVg8C9WKwriArrgg9zgZcbBAC5YdxLzIF-Gs4=.0e1cb86d-a849-4ce2-bc27-676dc9d0ce90@github.com> Message-ID: On Tue, 6 Jan 2026 19:23:15 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 seven additional commits since the last revision: >> >> - 2026 >> - Merge branch 'master' into 8374035.insert.styles >> - test >> - 26 >> - Merge branch 'master' into 8374035.insert.styles >> - Merge branch 'master' into 8374035.insert.styles >> - insert styles > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 600: > >> 598: /** >> 599: * Specifies the styles to be in effect for the characters to be inserted via user input. >> 600: * The value can be null. > > Can you document the behavior when this is null? Looking at the implementation, I think it takes the style at the caret position, but would be helpful to specify (also say whether there is a different depending on whether the caret is leading or trailing). updated the javadoc, should be clear now. the leading/trailing caret is irrelevant in this case, as it's determined by the model. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2017#discussion_r2666283596 From angorya at openjdk.org Tue Jan 6 21:43:10 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 21:43:10 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v7] In-Reply-To: References: Message-ID: <3r_oLrL-wN3yxAGDDjD1kJse9LHBxqpi8XZ2GshFrk8=.60fa5560-676b-4959-bbf7-6f11253fcdf7@github.com> On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx wrote: >> When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene. It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen. After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once). >> >> The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off. As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale. >> >> When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen). However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was. >> >> To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size. Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Avoid NaN's when determining screen Marked as reviewed by angorya (Reviewer). Looks good on macOS and Windows, I see no ill effects opening the monkey tester on external/internal screens with various scale factors. I've tested this branch merged with the latest master (please sync up the long running branches with the master). Also, please update the (c) to 2026 when you'll be removing the debug printouts. ------------- PR Review: https://git.openjdk.org/jfx/pull/2007#pullrequestreview-3632618005 PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3716462089 From angorya at openjdk.org Tue Jan 6 21:43:11 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 21:43:11 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v7] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:45:07 GMT, Martin Fox wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid NaN's when determining screen > > FWIW this can't be tested on Linux at the moment. It's possible to set up a system with multiple monitors each with a different scale but due to limitations in the GTK3 API we have to choose between supporting fractional scaling or per-monitor scaling. Currently we favor fractional and so we use the same scaling factor across all monitors. @beldenfox do you see any issues/regressions with/without an external monitor on linux? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2007#issuecomment-3716466138 From kcr at openjdk.org Tue Jan 6 21:48:59 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 21:48:59 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 01:45:10 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > align Linux/Windows behavior when clicking on resize border The updated API looks good. There is one typo in the javadoc tags that you will need to fix: a missing `@` before `since` in `rightProperty`. I'll review and approve the CSR next. modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 554: > 552: * > 553: * @defaultValue {@code null} > 554: * since 26 Typo: `since` --> `@since` ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3632618803 PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2666383003 From kcr at openjdk.org Tue Jan 6 21:56:22 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 21:56:22 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 01:45:10 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > align Linux/Windows behavior when clicking on resize border I haven't reviewed the implementation, but I'll try to do that later this week or next week. We will need at least one more reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3716499783 From kcr at openjdk.org Tue Jan 6 21:57:04 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 21:57:04 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v3] In-Reply-To: References: Message-ID: <1lvu--OCLcKNYUJErTt5HouiYF9HBS5iMoNYSHT2XLc=.0b1f0487-3585-40e9-b90c-778b1bb09c98@github.com> On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev wrote: >> # Use Case >> >> typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: >> - open MS Word or another rich text editor such as TextEdit >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. >> >> >> # Problem >> >> typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. >> >> >> # Solution >> >> - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/2017#pullrequestreview-3632653851 From angorya at openjdk.org Tue Jan 6 22:03:11 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 22:03:11 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 01:45:10 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > align Linux/Windows behavior when clicking on resize border modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 278: > 276: HT_UNSPECIFIED, > 277: HT_CAPTION, > 278: HT_CLIENT would it be better to declare int constants directly, especially since they are linked to the native declarations? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2666426696 From mstrauss at openjdk.org Tue Jan 6 22:52:34 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Jan 2026 22:52:34 GMT Subject: RFR: 8369836: Update HeaderBar API [v14] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - use native constants - typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/9776200a..c6331535 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=12-13 Stats: 31 lines in 3 files changed: 5 ins; 14 del; 12 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 Tue Jan 6 22:52:35 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Jan 2026 22:52:35 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:59:11 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> align Linux/Windows behavior when clicking on resize border > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 278: > >> 276: HT_UNSPECIFIED, >> 277: HT_CAPTION, >> 278: HT_CLIENT > > would it be better to declare int constants directly, especially since they are linked to the native declarations? Yes, you're right. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2666529248 From kcr at openjdk.org Tue Jan 6 23:23:07 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 23:23:07 GMT Subject: RFR: 8366739: ToolBar: overflow menu with fractional scale (2) [v5] In-Reply-To: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> References: <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com> Message-ID: On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond wrote: >> Fix overflow menu triggering due to floating-point precision error. >> >> At 1.25 display scaling on Windows, floating-point comparison errors (e.g. 109.60000000000001 > 109.6) cause the overflow menu to appear when the lefthand value is regarded as larger than the righthand value. >> >> These should be treated as equal (and therefore not display the overflow menu). >> >> This bug can happen in both horizontal and vertical toolbar orientation. >> >> The new tests added fail without this fix, and pass with it. An existing test has been re-factored slightly to allow re-use and more flexibility in specifying the scene's root node. > > Cormac Redmond has updated the pull request incrementally with one additional commit since the last revision: > > 8366739: remove pointless re-assignment of length I filed the following two JBS issues: [SKARA-2647](https://bugs.openjdk.org/browse/SKARA-2647): Skara's PR checks should warn if GHA workflows are not enabled in fork [JDK-8374655](https://bugs.openjdk.org/browse/JDK-8374655): Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo ------------- PR Comment: https://git.openjdk.org/jfx/pull/2016#issuecomment-3716705747 From mstrauss at openjdk.org Tue Jan 6 23:42:51 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 6 Jan 2026 23:42:51 GMT Subject: RFR: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged [v4] In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx wrote: >> This fixes a long standing bug with `GridPane` where unmanaged nodes would still result in gaps being added between rows/columns even though nothing is rendered there. Take the following grid where dashes and pipes represent the vgaps and hgaps: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |1 |C|||D| >> | |-|||-| >> |2 |E|||F| >> >> Now, when both C and D are set to unmanaged (and invisible) the grid will **still** render the gaps: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |1 ||||| >> | |-|||-| >> |2 |E|||F| >> >> Instead it should collapse the gap between row 0 and 2: >> >> | |0| |1| >> |--------|---|---|---| >> |0 |A|||B| >> | |-|||-| >> |2 |E|||F| >> >> There are at least two relevant issues in JBS: >> - A request to let the user show and hide rows and columns: https://bugs.openjdk.org/browse/JDK-8136901 >> - This can now be done by setting the relevant row/columns items to unmanaged without having to restructure the grid (assuming the complaint was that otherwise there'd be visible extra gaps for each hidden row) >> - A request for another mode to skip gaps when entire rows/columns are unmanaged: https://bugs.openjdk.org/browse/JDK-8092379 >> - This should not be a mode, but the standard, as unmanaged nodes should not affect the outcome of the grid layout >> >> Screenshots >> >> Simple application which can hide row 3: >> >> image >> >> Correct behavior when row 3 is hidden: >> >> image >> >> Behavior before this fix (note the double gap **and** extra grid line): >> >> image > > John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > When all nodes starting in a row or column are unmanaged, skip gap LGTM ------------- Marked as reviewed by mstrauss (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1990#pullrequestreview-3632859473 From angorya at openjdk.org Tue Jan 6 23:58:09 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 23:58:09 GMT Subject: RFR: 8369836: Update HeaderBar API [v14] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:52:34 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - use native constants > - typo So far looks good on macOS, I'll do more testing tomorrow. FYI, I've added Drag Type context menu that applies to all the header bar's children in the Stage page, use this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/update.header.bar.api Image modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 2: > 1: /* > 2: * Copyright (c) 2010, 2026, Oracle and/or its affiliates. All rights reserved. 2026? here and PickResultChooser, Stage, StageTesterWindow, GlassWindow.cpp ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3632784046 PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2666536915 From angorya at openjdk.org Tue Jan 6 23:58:10 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 6 Jan 2026 23:58:10 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:52:37 GMT, Kevin Rushforth wrote: > We will need at least one more reviewer. Does it mean 3 reviewers, @kevinrushforth ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3716771478 From kcr at openjdk.org Tue Jan 6 23:58:16 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 6 Jan 2026 23:58:16 GMT Subject: RFR: 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page Message-ID: This PR changes the links to the JBS home page -- https://bugs.openjdk.org/ -- to point to the JBS project page instead: https://bugs.openjdk.org/projects/JDK This avoids a potential problem where the JBS home page redirects to the login page for those without a JBS login. ------------- Commit messages: - JDK-8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page Changes: https://git.openjdk.org/jfx/pull/2027/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374567 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2027.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2027/head:pull/2027 PR: https://git.openjdk.org/jfx/pull/2027 From kcr at openjdk.org Wed Jan 7 00:18:04 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 00:18:04 GMT Subject: RFR: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo Message-ID: Adds a note to the "Testing" item for PR Authors to make sure that GHA is enabled for their personal fork. There is already a similar recommendation for Reviewers to check that. ------------- Commit messages: - 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo Changes: https://git.openjdk.org/jfx/pull/2028/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2028&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374655 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2028.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2028/head:pull/2028 PR: https://git.openjdk.org/jfx/pull/2028 From kcr at openjdk.org Wed Jan 7 00:19:22 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 00:19:22 GMT Subject: RFR: 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth wrote: > This PR changes the links to the JBS home page -- https://bugs.openjdk.org/ -- to point to the JBS project page instead: https://bugs.openjdk.org/projects/JDK > > This avoids a potential problem where the JBS home page redirects to the login page for those without a JBS login. @iclark Thanks for providing the workaround and for fixing the link on the [OpenJFX Wiki](https://wiki.openjdk.org/spaces/OpenJFX/overview). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2027#issuecomment-3716814044 From mstrauss at openjdk.org Wed Jan 7 00:19:52 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Jan 2026 00:19:52 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: update copyright year to 2026 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/c6331535..280d9d24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=13-14 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 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 kcr at openjdk.org Wed Jan 7 00:21:33 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 00:21:33 GMT Subject: RFR: 8369836: Update HeaderBar API [v13] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:56:03 GMT, Andy Goryachev wrote: > > We will need at least one more reviewer. > > Does it mean 3 reviewers, @kevinrushforth ? No, just 2. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3716817798 From iris at openjdk.org Wed Jan 7 00:31:15 2026 From: iris at openjdk.org (Iris Clark) Date: Wed, 7 Jan 2026 00:31:15 GMT Subject: RFR: 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth wrote: > This PR changes the links to the JBS home page -- https://bugs.openjdk.org/ -- to point to the JBS project page instead: https://bugs.openjdk.org/projects/JDK > > This avoids a potential problem where the JBS home page redirects to the login page for those without a JBS login. Marked as reviewed by iris (no project role). ------------- PR Review: https://git.openjdk.org/jfx/pull/2027#pullrequestreview-3632940720 From arapte at openjdk.org Wed Jan 7 06:12:04 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Jan 2026 06:12:04 GMT Subject: RFR: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth wrote: > Adds a note to the "Testing" item for PR Authors to make sure that GHA is enabled for their personal fork. There is already a similar recommendation for Reviewers to check that. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2028#pullrequestreview-3633477877 From arapte at openjdk.org Wed Jan 7 06:47:55 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Jan 2026 06:47:55 GMT Subject: RFR: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev wrote: >> Fixed two crashes: >> - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. >> - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 [v2] lgtm... ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2008#pullrequestreview-3633558247 From lkostyra at openjdk.org Wed Jan 7 07:13:56 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 7 Jan 2026 07:13:56 GMT Subject: RFR: 8269630: Bad clipboard data causes JVM to crash [v2] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra wrote: >> This commit fixes the JVM crash caused by bad Clipboard data on Linux. >> >> On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard. >> >> Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV. >> >> Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine. >> >> As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090). > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review: Move jstring cast Thanks for your reviews everyone! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3717602206 From lkostyra at openjdk.org Wed Jan 7 07:13:58 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 7 Jan 2026 07:13:58 GMT Subject: Integrated: 8269630: Bad clipboard data causes JVM to crash In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra wrote: > This commit fixes the JVM crash caused by bad Clipboard data on Linux. > > On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard. > > Moreover, `ClipboardContent` is simply an extension of `HashMap` which exposes `put()` and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV. > > Fix was done by type-checking incoming `ClipboardContent` data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine. > > As a side-note, this also shows there is discrepancy in how `Clipboard` operates between platforms. We should unify that behavior, but that is a larger task which will be solved under [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090). This pull request has now been integrated. Changeset: cfa34e61 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/cfa34e61534c71442591f011c921b62efedbfadd Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod 8269630: Bad clipboard data causes JVM to crash Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1999 From fthevenet at openjdk.org Wed Jan 7 07:32:27 2026 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Wed, 7 Jan 2026 07:32:27 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration Message-ID: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. ------------- Commit messages: - Use GtkFileChooserNative instead of GtkFileChooserDialog for file picker dialogs in gtk based glass Changes: https://git.openjdk.org/jfx/pull/2025/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374630 Stats: 15 lines in 1 file changed: 0 ins; 6 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/2025.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2025/head:pull/2025 PR: https://git.openjdk.org/jfx/pull/2025 From lkostyra at openjdk.org Wed Jan 7 07:51:12 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 7 Jan 2026 07:51:12 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev wrote: >> Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. >> >> This is a breaking change with low impact, ok since the feature is still incubating. > > 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: > > - 2026 > - Merge branch 'master' into 8374347.paragraph.direction > - set paragraph direction LGTM, quick confidence build and test run works fine. This was not used anywhere in our internal code and the feature is incubating so it's fine to rename. ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2021#pullrequestreview-3633709254 From lkostyra at openjdk.org Wed Jan 7 07:54:26 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 7 Jan 2026 07:54:26 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev wrote: >> # Use Case >> >> typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: >> - open MS Word or another rich text editor such as TextEdit >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. >> >> >> # Problem >> >> typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. >> >> >> # Solution >> >> - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by lkostyra (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2017#pullrequestreview-3633718809 From daniel.peintner at gmail.com Wed Jan 7 09:32:47 2026 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 7 Jan 2026 10:32:47 +0100 Subject: Proposal: make JavaFX cooperate better with Flatpak sand-boxing on Linux In-Reply-To: References: Message-ID: Hi Frederic, May I ask you about the correlation between jpackage and Flatpak. I encounter quite often the case that the library I build uses a different version of a dependent library as the one used on the target machine, which causes issues (I use jpackage to create the distros). I believe I understand this problem is tackled by Flatpak. However, I was wondering how Flatpak works in conjunction with jpackage. Can the technologies be combined? Thanks for your time, -- Daniel On Tue, Jan 6, 2026 at 5:24?PM Frederic Thevenet wrote: > Hi, > > I would like to discuss a change to the native implementation for > CommonDialogs::showFileChooser/showFolderChooser in the GTK back-end, > with the ultimate goal of making JavaFX based application work better > when packaged as Flatpak[0] under Linux. > > Flatpak is a framework for distributing desktop applications across > various Linux distributions, that runs each application into its own > sandbox to limit its access to the host environnement to the strict > minimum, including access to the network, HW devices or the host file > system. > It provides a specific set of APIs, known as "XDG Desktop Portal "[1] to > allow applications to only access resources the end user has > specifically requested, for example a specific file, and in order to > fully take advantage of Flatpak's containment feature, the guest > application needs to be aware of these API; which is not the case for > Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into > GTK3 which should be easy to surface so that JavaFX can benefit from it > in a transparent way. > > One such opportunity is the e File Chooser portal, wich make apps use > the file picker dialog native to the desktop environment they?re running > on, and dynamically grants permissions to the host file system to > sandboxed apps, on a strictly need-to-access basis (i.e. the application > is granted access only the files picked by the user using the file > chooser dialog, transparently). > In order to let JavaFX based apps opt into this feature, we need to > replace explicit use of GtkFileChooserDialog[2] with > GtkFileChooserNative[3], which is only a small change, and should > completely transparent when an app is run normally, outside of a sandbox > since the gtk glass implementation is only used on Linux anyway. I have > prototyped it as a draft PR[4] and as you'll see, the changes are minimal. > > There are other aspects of the sandboxing that currently aren't > supported well by Java/JavaFX applications and that this won't solve, > such as the fact the java.nio.file APIs will remain unaware of the > sandbox and so will refer to the files picked by the FileChooser using a > path that is opaque for the end user (e.g. > "/run/user/1000/doc/adda6d11f/foo.bar" instead of > "~/Downloads/foo.bar"), but this is a first step, that I believe still > has much value and no obvious drawback, and I would very much like to > see it considered for inclusion. > > Thanks! > > [0] https://docs.flatpak.org/en/latest/introduction.html > [1] https://flatpak.github.io/xdg-desktop-portal/docs/ > [2] https://docs.gtk.org/gtk3/class.FileChooserNative.html > [3] https://docs.gtk.org/gtk3/class.FileChooserDialog.html > [4] https://github.com/openjdk/jfx/pull/2025 > > -- > Frederic Thevenet > Senior Software Engineer - OpenJDK > Red Hat France > BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fthevene at redhat.com Wed Jan 7 10:53:44 2026 From: fthevene at redhat.com (Frederic Thevenet) Date: Wed, 7 Jan 2026 11:53:44 +0100 Subject: Proposal: make JavaFX cooperate better with Flatpak sand-boxing on Linux In-Reply-To: References: Message-ID: <0a59f3ae-5360-4086-959a-281c8472a238@redhat.com> Hi Daniel, Yes, jpackage and Flatpak are very much complementary technologies. Ultimately, Flatpak is just a mean to isolate and run an arbitrary binary bundle in a container-like environnement; in the case of a Java-based app it makes a lot of sense to use jpackage to generate that bundle. This is precisely what I do to package my own app, if you'd like an example: [0] [1] (the first link shows the jpackage parameters I use to build a runtime image, the second shows the options I use to set up the Flatpak "manifest"). Cheers, Frederic [0] https://github.com/binjr/binjr/blob/a93c1bfeb024209cf6e86bfb31ef66b7ffe97a02/build.gradle#L653 [1] https://github.com/flathub/eu.binjr.binjr/blob/master/eu.binjr.binjr.yml On 1/7/26 10:32 AM, Daniel Peintner wrote: > Hi Frederic, > > May I ask you about the correlation between jpackage and Flatpak. > > I encounter quite often the case that the library I build uses a > different version of a dependent library?as the one used on the target > machine, which causes issues (I use jpackage to create the distros). > I believe I understand this problem is tackled by Flatpak. However, I > was wondering how Flatpak works in conjunction?with jpackage.?Can the > technologies be combined? > > Thanks for your time, > > -- Daniel > > > > > On Tue, Jan 6, 2026 at 5:24?PM Frederic Thevenet > wrote: > > Hi, > > I would like to discuss a change to the native implementation for > CommonDialogs::showFileChooser/showFolderChooser in the GTK back-end, > with the ultimate goal of making JavaFX based application work better > when packaged as Flatpak[0] under Linux. > > Flatpak is a framework for distributing desktop applications across > various Linux distributions, that runs each application into its own > sandbox to limit its access to the host environnement to the strict > minimum, including access to the network, HW devices or the host file > system. > It provides a specific set of APIs, known as "XDG Desktop Portal > "[1] to > allow applications to only access resources the end user has > specifically requested, for example a specific file, and in order to > fully take advantage of Flatpak's containment feature, the guest > application needs to be aware of these API; which is not the case for > Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked > into > GTK3 which should be easy to surface so that JavaFX can benefit > from it > in a transparent way. > > One such opportunity is the e File Chooser portal, wich make apps use > the file picker dialog native to the desktop environment they?re > running > on, and dynamically grants permissions to the host file system to > sandboxed apps, on a strictly need-to-access basis (i.e. the > application > is granted access only the files picked by the user using the file > chooser dialog, transparently). > In order to let JavaFX based apps opt into this feature, we need to > replace explicit use of GtkFileChooserDialog[2] with > GtkFileChooserNative[3], which is only a small change, and should > completely transparent when an app is run normally, outside of a > sandbox > since the gtk glass implementation is only used on Linux anyway. I > have > prototyped it as a draft PR[4] and as you'll see, the changes are > minimal. > > There are other aspects of the sandboxing that currently aren't > supported well by Java/JavaFX applications and that this won't solve, > such as the fact the? java.nio.file APIs will remain unaware of the > sandbox and so will refer to the files picked by the FileChooser > using a > path that is opaque for the end user (e.g. > "/run/user/1000/doc/adda6d11f/foo.bar" instead of > "~/Downloads/foo.bar"), but this is a first step, that I believe > still > has much value and no obvious drawback, and I would very much like to > see it considered for inclusion. > > Thanks! > > [0] https://docs.flatpak.org/en/latest/introduction.html > [1] https://flatpak.github.io/xdg-desktop-portal/docs/ > [2] https://docs.gtk.org/gtk3/class.FileChooserNative.html > [3] https://docs.gtk.org/gtk3/class.FileChooserDialog.html > [4] https://github.com/openjdk/jfx/pull/2025 > > -- > Frederic Thevenet > Senior Software Engineer - OpenJDK > Red Hat France > BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 > -- Frederic Thevenet Senior Software Engineer - OpenJDK Red Hat France BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Wed Jan 7 11:02:53 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Jan 2026 11:02:53 GMT Subject: RFR: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth wrote: > Adds a note to the "Testing" item for PR Authors to make sure that GHA is enabled for their personal fork. There is already a similar recommendation for Reviewers to check that. As discussed, this a good enhancement. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/2028#pullrequestreview-3634348913 From mhanl at openjdk.org Wed Jan 7 11:25:54 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 7 Jan 2026 11:25:54 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v3] In-Reply-To: References: Message-ID: <9oUxymOQCthDVoSH614ifOAwhLkoeVrh0ugegfGSblg=.64b79458-b85c-41ec-b965-cff727068a72@github.com> On Wed, 24 Dec 2025 17:49:26 GMT, Christopher Schnick wrote: >> This is a pretty simple fix for the accessible text of password fields. > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Fix test format Note that GHA builds need to be enabled before proceeding. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3718421617 From hmeda at openjdk.org Wed Jan 7 11:52:12 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 7 Jan 2026 11:52:12 GMT Subject: RFR: 8374153: Add a MAX_COMPILE_THREADS gradle property to limit number of threads In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 18:29:43 GMT, Kevin Rushforth wrote: > This PR adds a new `MAX_COMPILE_THREADS` gradle property to to limit the number of build-time parallel compilation threads to the smaller of this property and the number of avialable processors. > > Our gradle build spawns up to `NUM_COMPILE_THREADS` compilation tasks in parallel when building native libraries. By default, `NUM_COMPILE_THREADS` is set to the value returned by `Runtime.getRuntime().availableProcessors()`. That value can be overridden on the command line by setting the `NUM_COMPILE_THREADS` gradle property. We need a way to clamp `NUM_COMPILE_THREADS` at some maximum value without the caller having to compute it. > > The change in `build.gradle` is simple: > > * Define a new `MAX_COMPILE_THREADS` gradle property, which will default to 0 (meaning unlimited) for compatibility with current behavior. > > * Set the default value of `NUM_COMPILE_THREADS` as follows: > > > NUM_COMPILE_THREADS = MAX_COMPILE_THREADS > 0 > ? Math.min(MAX_COMPILE_THREADS, availableProcessors) > : availableProcessors( > > > This will allow a test scripts that runs on a number of different platforms to clamp to a maximum value without having to use jshell or similar to implement `Math.min(MAX_COMPILE_THREADS, Runtime.getRuntime().availableProcessors())` in the script. > > We have a practical need for this in our headful test systems, several of which report a higher number of processors than they can effectively support. Without clamping, the build will either run slower (due to too much swapping) or fail altogether when building WebKit. LGTM. ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/2014#pullrequestreview-3634510230 From zelmidaoui at openjdk.org Wed Jan 7 13:25:41 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 7 Jan 2026 13:25:41 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev wrote: >> Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. >> >> This is a breaking change with low impact, ok since the feature is still incubating. > > 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: > > - 2026 > - Merge branch 'master' into 8374347.paragraph.direction > - set paragraph direction LGTM, simple change and works fine. ------------- Marked as reviewed by zelmidaoui (Committer). PR Review: https://git.openjdk.org/jfx/pull/2021#pullrequestreview-3634863378 From kcr at openjdk.org Wed Jan 7 13:30:23 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 13:30:23 GMT Subject: Integrated: 8374153: Add a MAX_COMPILE_THREADS gradle property to limit number of threads In-Reply-To: References: Message-ID: <_p2gOZ3U6EZOQJyuhOWALKYbyuwB4sLv4VeD_vtTw1I=.8060acc4-b228-45e6-b19e-3e6d3ced02f7@github.com> On Fri, 19 Dec 2025 18:29:43 GMT, Kevin Rushforth wrote: > This PR adds a new `MAX_COMPILE_THREADS` gradle property to to limit the number of build-time parallel compilation threads to the smaller of this property and the number of avialable processors. > > Our gradle build spawns up to `NUM_COMPILE_THREADS` compilation tasks in parallel when building native libraries. By default, `NUM_COMPILE_THREADS` is set to the value returned by `Runtime.getRuntime().availableProcessors()`. That value can be overridden on the command line by setting the `NUM_COMPILE_THREADS` gradle property. We need a way to clamp `NUM_COMPILE_THREADS` at some maximum value without the caller having to compute it. > > The change in `build.gradle` is simple: > > * Define a new `MAX_COMPILE_THREADS` gradle property, which will default to 0 (meaning unlimited) for compatibility with current behavior. > > * Set the default value of `NUM_COMPILE_THREADS` as follows: > > > NUM_COMPILE_THREADS = MAX_COMPILE_THREADS > 0 > ? Math.min(MAX_COMPILE_THREADS, availableProcessors) > : availableProcessors( > > > This will allow a test scripts that runs on a number of different platforms to clamp to a maximum value without having to use jshell or similar to implement `Math.min(MAX_COMPILE_THREADS, Runtime.getRuntime().availableProcessors())` in the script. > > We have a practical need for this in our headful test systems, several of which report a higher number of processors than they can effectively support. Without clamping, the build will either run slower (due to too much swapping) or fail altogether when building WebKit. This pull request has now been integrated. Changeset: 1e6c94b3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1e6c94b3c46db66df5856183859e05a683d1249a Stats: 23 lines in 2 files changed: 20 ins; 0 del; 3 mod 8374153: Add a MAX_COMPILE_THREADS gradle property to limit number of threads Reviewed-by: arapte, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/2014 From arapte at openjdk.org Wed Jan 7 15:10:16 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 7 Jan 2026 15:10:16 GMT Subject: Integrated: 8374573: Update copyright header for files modified in 2025 In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 07:38:07 GMT, Ambarish Rapte wrote: > As we enter year 2026, update copyright year in files updated in the year 2025. This pull request has now been integrated. Changeset: 237fe643 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/237fe643e2ae5965dcfa3081d840708bbc3c851d Stats: 50 lines in 50 files changed: 0 ins; 0 del; 50 mod 8374573: Update copyright header for files modified in 2025 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/2024 From angorya at openjdk.org Wed Jan 7 15:29:16 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 15:29:16 GMT Subject: RFR: 8374347: StyleAttributeMap.Builder.setParagraphDirection() [v2] In-Reply-To: References: Message-ID: <1eAJWFfiNQmO9FM2DfhE-rUp3ZWiZcHxuYhtK0snO00=.8dd5d301-86db-4209-9475-5d58739046be@github.com> On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev wrote: >> Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. >> >> This is a breaking change with low impact, ok since the feature is still incubating. > > 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: > > - 2026 > - Merge branch 'master' into 8374347.paragraph.direction > - set paragraph direction thank you all! ------------- PR Comment: https://git.openjdk.org/jfx/pull/2021#issuecomment-3719393814 From angorya at openjdk.org Wed Jan 7 15:29:17 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 15:29:17 GMT Subject: Integrated: 8374347: StyleAttributeMap.Builder.setParagraphDirection() In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 22:37:47 GMT, Andy Goryachev wrote: > Renaming `setRTL(ParagraphDirection)` -> `setParagraphDirection(ParagraphDirection)` in the `StyleAttributeMap.Builder` class. > > This is a breaking change with low impact, ok since the feature is still incubating. This pull request has now been integrated. Changeset: c549e831 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/c549e83135b6d0e1fea4e38825409fbe9be2f72f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8374347: StyleAttributeMap.Builder.setParagraphDirection() Reviewed-by: kcr, lkostyra, zelmidaoui ------------- PR: https://git.openjdk.org/jfx/pull/2021 From angorya at openjdk.org Wed Jan 7 15:31:51 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 15:31:51 GMT Subject: RFR: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth wrote: > Adds a note to the "Testing" item for PR Authors to make sure that GHA is enabled for their personal fork. There is already a similar recommendation for Reviewers to check that. You _could_ provide a link to the "Actions" tab, though it might break when using a branch or if guthub changes the tree structure, so perhaps better not. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2028#pullrequestreview-3635438073 From angorya at openjdk.org Wed Jan 7 15:41:07 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 15:41:07 GMT Subject: RFR: 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth wrote: > This PR changes the links to the JBS home page -- https://bugs.openjdk.org/ -- to point to the JBS project page instead: https://bugs.openjdk.org/projects/JDK > > This avoids a potential problem where the JBS home page redirects to the login page for those without a JBS login. The new link correctly redirects to the list of issues instead of the Dashboard (in an incognito window, under VPN): Image ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2027#pullrequestreview-3635496846 From duke at openjdk.org Wed Jan 7 15:41:25 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 7 Jan 2026 15:41:25 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: > This is a pretty simple fix for the accessible text of password fields. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Trigger Build ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2020/files - new: https://git.openjdk.org/jfx/pull/2020/files/cf88e11f..5092d677 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2020&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2020&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2020.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2020/head:pull/2020 PR: https://git.openjdk.org/jfx/pull/2020 From almatvee at openjdk.org Wed Jan 7 16:06:55 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 Jan 2026 16:06:55 GMT Subject: Integrated: 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev wrote: > Fixed two crashes: > - `shouldWaitForLoadingOfRequestedResource()` was not synchronized with `dispose()`. > - `AddBand()`, `RemoveBand()` and `MoveBand()` was not synchronized with `ProcessBufferLists()`. This pull request has now been integrated. Changeset: 82865528 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/82865528a1867fa8ebab8d57365bfa892d0d7def Stats: 107 lines in 4 files changed: 46 ins; 19 del; 42 mod 8373058: Media crash when playing MP3 over JRT protocol on macOS 26 Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/2008 From kcr at openjdk.org Wed Jan 7 17:11:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 17:11:46 GMT Subject: RFR: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:29:27 GMT, Andy Goryachev wrote: > You _could_ provide a link to the "Actions" tab, though it might break when using a branch or if guthub changes the tree structure, so perhaps better not. Even if we wanted to (which I agree we don't), we couldn't do this anyway; the link is to the Actions tab in the personal fork of the particular GitHub user who is creating a PR, so it isn't a set link. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2028#issuecomment-3719860883 From kcr at openjdk.org Wed Jan 7 18:10:02 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 18:10:02 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v8] In-Reply-To: References: <0S7begIloxySJN5oynf5xlFcp4FmEWczS743LUBtnBM=.3f49cde7-9424-42c7-9fc8-a86c3abb70d2@github.com> Message-ID: On Mon, 29 Dec 2025 09:10:39 GMT, Pabulaner IV wrote: >> Pabulaner IV has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX > > Thanks for the fast reply! > > I have removed all external dependencies and added a main method to each test. > I also have added a README.md on how to compile and run the tests, since You need to add the javafx modules. @pabulaner The latest version of the tests build and run fine for me. Thanks! I'll do some additional testing and complete my review very soon. In the mean time, can you do two thing? 1. Enable GitHub Actions (GHA) Workflows in your personal fork. This will allow sanity tests to run when you push code changes to your branch of your personal fork, and allow the Skara bot to report the results of the tests in the PR. Navigate to the home page of your GitHub repo, click on the "Actions" tab, and then click on the green button that says something like: "I understand my workflows, go ahead and enable them". 2. Merge (not rebase) the latest upstream master into your branch and push it. That will trigger a GHA test run on your now-up-to-date branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3720107970 From angorya at openjdk.org Wed Jan 7 18:18:37 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 18:18:37 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:19:52 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year to 2026 Wanted to comment on naming, since it might impact the CSR. macOS looks good; continuing testing on Windows... modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderDragType.java line 118: > 116: * @since 26 > 117: */ > 118: TRANSPARENT, TRANSPARENT* might be confusing, maybe DRAG_TRANSPARENT* or some such? ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3635925366 PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2669334666 From kcr at openjdk.org Wed Jan 7 18:24:33 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jan 2026 18:24:33 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v9] In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 09:15:28 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 The tests all work as expected. The only thing I notice is that they don't always exit when the last window is closed, but given the nature of the tests, that isn't surprising. Improving this could be done as a follow-up. In parallel with your enabling a GHA run, I'll do one last CI headful test run. When both are successful, I'll approve it. ------------- PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3636232120 From angorya at openjdk.org Wed Jan 7 18:54:41 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 18:54:41 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:19:52 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year to 2026 Found a weird issue on Windows that I cannot reproduce on macOS: https://github.com/user-attachments/assets/1917d54e-1ddc-434b-ad3e-1b88f9a08834 To reproduce using the monkey tester from this branch: https://github.com/andy-goryachev-oracle/MonkeyTest/tree/update.header.bar.api - split header bar - click and hold on the "Right" button - while holding the mouse button, move the mouse near the split pane divider Notice the divider unexpectedly moves. Once you release the button, it may not reproduce anymore, unless you move the window. (this might be addressed in a follow-up bug, I think) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3720278382 From angorya at openjdk.org Wed Jan 7 19:00:29 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 19:00:29 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:19:52 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year to 2026 Looks good enough on macOS/Windows (I can't test on Linux), since it's a preview feature. One issue can be addressed in a follow-up. I'll re-approve if you decide to rename the TRANPARENT* enums. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3636370467 From angorya at openjdk.org Wed Jan 7 20:06:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 20:06:39 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v9] In-Reply-To: References: Message-ID: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> On Mon, 29 Dec 2025 09:15:28 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 Some minor comments, one exception, and many tests hang on closing using the system menu, or the quit menu in the dock, or the close icon in the title bar. tests/manual/systemmenu/MacOSSystemMenuJFXPanelSwingFirstTest.java line 61: > 59: > 60: public void test() throws InterruptedException, IOException { > 61: initSwing(List.of(TEST_MENUS_0, TEST_MENUS_1)); It would be nice to have some instructions / acceptance criteria in each test. Assume the tester knows nothing about the issue. tests/manual/systemmenu/MacOSSystemMenuMultiWindowTest.java line 57: > 55: new MacOSSystemMenuMultiWindowTest().test(); > 56: } > 57: I've got this upon exiting via system menu "Quit java" once: Exception in thread "InvokeLaterDispatcher" java.lang.RuntimeException: Main Java thread is detached. at javafx.graphics at 26-internal/com.sun.glass.ui.mac.MacApplication._submitForLaterInvocation(Native Method) at javafx.graphics at 26-internal/com.sun.glass.ui.mac.MacApplication.submitForLaterInvocation(MacApplication.java:375) at javafx.graphics at 26-internal/com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:122) Also, if I just launch it and then immediately select "Quit java" from the system menu, it hangs with a beach ball and requires ctrl-C in the terminal to kill it. tests/manual/systemmenu/MacOSSystemMenuMultiWindowWithSwingFirstTest.java line 55: > 53: > 54: public static void main(String[] args) throws InterruptedException, IOException { > 55: new MacOSSystemMenuMultiWindowWithSwingFirstTest().test(); this test requires selecting SourceLauncher -> Quit java from the system menu twice to close - is this intentional? tests/manual/systemmenu/MacOSSystemMenuMultiWindowWithSwingFirstTest.java line 62: > 60: initJavaFX(List.of(TEST_MENUS_1, TEST_MENUS_3)); > 61: > 62: focusJavaFX(0); Minor: noticed that the "Next" button seem to work only once in this and other tests. Is it intentional? tests/manual/systemmenu/MacOSSystemMenuSingleWindowWithSwingFirstTest.java line 56: > 54: > 55: public static void main(String[] args) throws InterruptedException, IOException { > 56: new MacOSSystemMenuSingleWindowWithSwingFirstTest().test(); this test hangs when fx window is closed first via the close title bar icon, followed by closing the swing window with same method. tests/manual/systemmenu/README.md line 3: > 1: # Compiling and Running > 2: > 3: To compile the tests, run the following command: Actually, separate compile step is not necessary, the test apps run with the following command from within this directory (you do need to run the gradle build first): java --module-path ../../../build/sdk/lib/ --add-modules javafx.controls,javafx.fxml,javafx.swing MacOSSystemMenuJFXPanelSwingFirstTest.java ------------- PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3636469005 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669807380 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669843101 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669882110 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669885390 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669899163 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2669796415 From angorya at openjdk.org Wed Jan 7 21:06:18 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 21:06:18 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 To add to an earlier discussion regarding the number of iterations required for the layout to converge: there are situations where the layout goes into infinite update mode - I've seen these back in java 8 fx days, and it might happen even today. Below is an example I captured with the monkey tester on 2025/12/03 using the current the master branch of that day: https://github.com/user-attachments/assets/1a4cd2d5-4b71-4f25-b43b-287f22f10f82 The video could not capture the flicker exactly probably due to capture limitations, but the flicker continued until the user clicks on something or resizes the window. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3720788832 From jhendrikx at openjdk.org Wed Jan 7 21:25:32 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Jan 2026 21:25:32 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 > To add to an earlier discussion regarding the number of iterations required for the layout to converge: there are situations where the layout goes into infinite update mode - I've seen these back in java 8 fx days, and it might happen even today. > > Below is an example I captured with the monkey tester on 2025/12/03 using the current the master branch of that day: > > video1256508024.mp4 > The video could not capture the flicker exactly probably due to capture limitations, but the flicker continued until the user clicks on something or resizes the window. It's nothing that can be resolved directly by some outside intervention, it just a bug in (what looks like) `ListView`. Only debugging what is triggering a new layout pass each time will help find the cause. These kind of bugs are unavoidable when controls or skins are not producing stable results from their layout calculations. Often calculations eventually converge, but that's really only the best case scenario, and certainly not the only possible outcome. You seem to have found a case where the calculations are not converging. This is why IMHO any layout that relies on convergence is already broken; it just happens to broken in a way that eventually leads to a stable result... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3720863015 From jhendrikx at openjdk.org Wed Jan 7 21:27:07 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Jan 2026 21:27:07 GMT Subject: Integrated: 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 16:04:51 GMT, John Hendrikx wrote: > This fixes a long standing bug with `GridPane` where unmanaged nodes would still result in gaps being added between rows/columns even though nothing is rendered there. Take the following grid where dashes and pipes represent the vgaps and hgaps: > > | |0| |1| > |--------|---|---|---| > |0 |A|||B| > | |-|||-| > |1 |C|||D| > | |-|||-| > |2 |E|||F| > > Now, when both C and D are set to unmanaged (and invisible) the grid will **still** render the gaps: > > | |0| |1| > |--------|---|---|---| > |0 |A|||B| > | |-|||-| > |1 ||||| > | |-|||-| > |2 |E|||F| > > Instead it should collapse the gap between row 0 and 2: > > | |0| |1| > |--------|---|---|---| > |0 |A|||B| > | |-|||-| > |2 |E|||F| > > There are at least two relevant issues in JBS: > - A request to let the user show and hide rows and columns: https://bugs.openjdk.org/browse/JDK-8136901 > - This can now be done by setting the relevant row/columns items to unmanaged without having to restructure the grid (assuming the complaint was that otherwise there'd be visible extra gaps for each hidden row) > - A request for another mode to skip gaps when entire rows/columns are unmanaged: https://bugs.openjdk.org/browse/JDK-8092379 > - This should not be a mode, but the standard, as unmanaged nodes should not affect the outcome of the grid layout > > Screenshots > > Simple application which can hide row 3: > > image > > Correct behavior when row 3 is hidden: > > image > > Behavior before this fix (note the double gap **and** extra grid line): > > image This pull request has now been integrated. Changeset: d997dd8b Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/d997dd8b7eb6665bbd6890f6cabb4e22a4950e4a Stats: 51 lines in 1 file changed: 27 ins; 4 del; 20 mod 8092379: GridPane should not render extra gaps when entire rows or columns are unmanaged Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1990 From jhendrikx at openjdk.org Wed Jan 7 21:34:45 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 7 Jan 2026 21:34:45 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v8] In-Reply-To: References: Message-ID: > When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene. It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen. After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once). > > The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off. As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale. > > When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen). However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was. > > To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size. Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale). John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Remove empty lines - Remove debug prints ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2007/files - new: https://git.openjdk.org/jfx/pull/2007/files/534204ee..c4d39f7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2007&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2007&range=06-07 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2007.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2007/head:pull/2007 PR: https://git.openjdk.org/jfx/pull/2007 From angorya at openjdk.org Wed Jan 7 21:34:46 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 21:34:46 GMT Subject: RFR: 8373688: Wrong render scale is used if Window is on another screen when Scene is sized [v8] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 21:31:11 GMT, John Hendrikx wrote: >> When a Window is created with a certain X/Y coordinate to place it on a specific screen, and is subsequently shown for the first time, one of the first things it does is size the window according to the size of the Scene. It does this based on the render scale of the *primary* screen as it has not moved the peer yet to the correct screen. After the scene has been sized, it is moved to the correct screen, triggering a change of render scale, but not a resizing of the Window (as this is only done once). >> >> The result of this is that due to slight difference in render scale, the size calculated for the scene may be a few pixels off. As the scene's preferred size is used for this calculation, even a few pixels too small can result in Labels being shown with ellipsis on the intended target screen with a different render scale. >> >> When observing the render scale X or Y property, one can observe a change from 1.0 (the default value) to 2.0 (the primary screen's render scale) to another value (depending on the target screen). However, the Window involved (being positioned by the user using setX()/setY() before it is shown) was never shown on the primary screen, yet the size calculation assumed it was. >> >> To solve this problem, the peer should be moved to the correct screen **before** asking the Scene for its preferred size to use as the initial Window size. Doing so (by adding an additional `applyBounds` call) also results in the render scale properties to only change once (or not at all) from their default value to the target screen's value (or not at all if the target screen is 1.0 scale). > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove empty lines > - Remove debug prints Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2007#pullrequestreview-3636870830 From angorya at openjdk.org Wed Jan 7 21:43:35 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 21:43:35 GMT Subject: RFR: 8374035: RichTextArea: add insertStyles property [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev wrote: >> # Use Case >> >> typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: >> - open MS Word or another rich text editor such as TextEdit >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. >> >> >> # Problem >> >> typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. >> >> >> # Solution >> >> - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Thank you all! ------------- PR Comment: https://git.openjdk.org/jfx/pull/2017#issuecomment-3720927769 From angorya at openjdk.org Wed Jan 7 21:48:48 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 21:48:48 GMT Subject: Integrated: 8374035: RichTextArea: add insertStyles property In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev wrote: > # Use Case > > typing into RichTextArea with a default model (or any other model that supports discrete styles), in the presence of a tool bar or similar UI that allows to specify the styles to take effect on the next key press. Example: > - open MS Word or another rich text editor such as TextEdit > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > > # Problem > > typing a character uses the model's logic to deal with the styles, via StyledTextModel::replace(StyleResolver resolver, TextPos start, TextPos end, String text) method, see RichTextAreaBehavior::handleTypedChar(). This worked well initially, however it makes it impossible (without extending RichTextAreaBehavior which is not a public class) to implement the behavior described earlier. > > > # Solution > > - add 'insertStyles' property to the RichTextArea, which will override the model styles in RichTextAreaBehavior::handleTypedChar() if the value is not null This pull request has now been integrated. Changeset: 9c913f2b Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/9c913f2b42afb2bd025751ea479f2d668a910fee Stats: 81 lines in 3 files changed: 76 ins; 0 del; 5 mod 8374035: RichTextArea: add insertStyles property Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/2017 From angorya at openjdk.org Wed Jan 7 22:36:13 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 22:36:13 GMT Subject: RFR: 8367557: Extended stage seems to hang after drag and drop In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? wrote: > An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window: > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.input.ClipboardContent; > import javafx.scene.input.Dragboard; > import javafx.scene.input.TransferMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.HeaderBar; > import javafx.stage.Stage; > import javafx.stage.StageStyle; > > public class DragDropTest extends Application { > > @Override > public void start(Stage primaryStage) { > > primaryStage.initStyle(StageStyle.EXTENDED); > > // Create drag source > Label dragSource = new Label("Drag me!"); > dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px"); > > // Create drop target > Label dropTarget = new Label("Drop here!"); > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > > // Set up drag detection > dragSource.setOnDragDetected(event -> { > Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY); > ClipboardContent content = new ClipboardContent(); > content.putString("Hello from drag source!"); > dragboard.setContent(content); > event.consume(); > }); > > // Set up drag over > dropTarget.setOnDragOver(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > event.acceptTransferModes(TransferMode.COPY); > } > event.consume(); > }); > > // Set up drag entered (visual feedback) > dropTarget.setOnDragEntered(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > } > event.consume(); > }); > > // Set up drag exited (reset visual feedback) > dropTarget.setOnDragExited(event -> { > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > event.consume(); > }); > > // Set up drop > dropTarget.setOnD... Could this bug be related to https://github.com/openjdk/jfx/pull/1936#issuecomment-3720278382 ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2003#issuecomment-3721094013 From mfox at openjdk.org Wed Jan 7 22:39:51 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 7 Jan 2026 22:39:51 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v8] In-Reply-To: References: <0S7begIloxySJN5oynf5xlFcp4FmEWczS743LUBtnBM=.3f49cde7-9424-42c7-9fc8-a86c3abb70d2@github.com> Message-ID: On Wed, 7 Jan 2026 18:07:33 GMT, Kevin Rushforth wrote: >> Thanks for the fast reply! >> >> I have removed all external dependencies and added a main method to each test. >> I also have added a README.md on how to compile and run the tests, since You need to add the javafx modules. > > @pabulaner The latest version of the tests build and run fine for me. Thanks! > > I'll do some additional testing and complete my review very soon. In the mean time, can you do two thing? > > 1. Enable GitHub Actions (GHA) Workflows in your personal fork. This will allow sanity tests to run when you push code changes to your branch of your personal fork, and allow the Skara bot to report the results of the tests in the PR. Navigate to the home page of your GitHub repo, click on the "Actions" tab, and then click on the green button that says something like: "I understand my workflows, go ahead and enable them". > 2. Merge (not rebase) the latest upstream master into your branch and push it. That will trigger a GHA test run on your now-up-to-date branch. @kevinrushforth has indicated that he would like to get this into jfx26 if possible so we might want to move some of this cleanup to a follow-up PR. At a minimum the JavaFX windows need to be made larger so the user can see the entire menu tree. And some instructions need to be added to the README. As I understand it the user should launch the test, verify that the contents of the system menu bar match what's in the currently focused window, press the Next button, verify, press Next, verify, etc. The big issue is that the tests enter what are essentially busy loops waiting for the user to press Next. If you don't keep pressing Next all the way to the end things get very confusing. I think that needs to be re-thought but, again, we might want to push a re-write of that scope off to another PR. A smaller issue is that the user doesn't know when to stop pressing Next. If there's an easy fix for that (like removing the Next button from the last window) you might consider doing that. The one area not covered by these tests is what happens when *all* windows lose focus. The easiest way to make this happen is to iconify them all. Unfortunately this means there will be no windows around to provide guidance to the user. You might want to add a brief sentence to the README suggesting that after a test is done the user should iconify all the windows and verify that some system menu is still around. It's difficult to summarize what the expected results are. For strictly JavaFX windows they should see a single menu. For a mix of Swing and JavaFX windows they should see the set of menus associated with the last Swing window that had focus (assuming they can remember which one that was). Probably good enough to have the tester iconify all the windows and verify that the system doesn't explode. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3721102930 From mfox at openjdk.org Wed Jan 7 22:43:57 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 7 Jan 2026 22:43:57 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v9] In-Reply-To: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> References: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> Message-ID: On Wed, 7 Jan 2026 19:24:25 GMT, Andy Goryachev wrote: >> 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 > > tests/manual/systemmenu/README.md line 3: > >> 1: # Compiling and Running >> 2: >> 3: To compile the tests, run the following command: > > Actually, separate compile step is not necessary, the test apps run with the following command from within this directory (you do need to run the gradle build first): > > > java --module-path ../../../build/sdk/lib/ --add-modules javafx.controls,javafx.fxml,javafx.swing MacOSSystemMenuJFXPanelSwingFirstTest.java Even easier: `java @../../../build/run.args MacOSSystemMenuMultiWindowTest.java ` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2670293524 From angorya at openjdk.org Wed Jan 7 23:18:18 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 7 Jan 2026 23:18:18 GMT Subject: RFR: 8367557: Extended stage seems to hang after drag and drop In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? wrote: > An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window: > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.input.ClipboardContent; > import javafx.scene.input.Dragboard; > import javafx.scene.input.TransferMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.HeaderBar; > import javafx.stage.Stage; > import javafx.stage.StageStyle; > > public class DragDropTest extends Application { > > @Override > public void start(Stage primaryStage) { > > primaryStage.initStyle(StageStyle.EXTENDED); > > // Create drag source > Label dragSource = new Label("Drag me!"); > dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px"); > > // Create drop target > Label dropTarget = new Label("Drop here!"); > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > > // Set up drag detection > dragSource.setOnDragDetected(event -> { > Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY); > ClipboardContent content = new ClipboardContent(); > content.putString("Hello from drag source!"); > dragboard.setContent(content); > event.consume(); > }); > > // Set up drag over > dropTarget.setOnDragOver(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > event.acceptTransferModes(TransferMode.COPY); > } > event.consume(); > }); > > // Set up drag entered (visual feedback) > dropTarget.setOnDragEntered(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > } > event.consume(); > }); > > // Set up drag exited (reset visual feedback) > dropTarget.setOnDragExited(event -> { > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > event.consume(); > }); > > // Set up drop > dropTarget.setOnD... Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2003#pullrequestreview-3637155112 From mstrauss at openjdk.org Wed Jan 7 23:34:59 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Jan 2026 23:34:59 GMT Subject: RFR: 8367557: Extended stage seems to hang after drag and drop In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? wrote: > An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window: > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.input.ClipboardContent; > import javafx.scene.input.Dragboard; > import javafx.scene.input.TransferMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.HeaderBar; > import javafx.stage.Stage; > import javafx.stage.StageStyle; > > public class DragDropTest extends Application { > > @Override > public void start(Stage primaryStage) { > > primaryStage.initStyle(StageStyle.EXTENDED); > > // Create drag source > Label dragSource = new Label("Drag me!"); > dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px"); > > // Create drop target > Label dropTarget = new Label("Drop here!"); > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > > // Set up drag detection > dragSource.setOnDragDetected(event -> { > Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY); > ClipboardContent content = new ClipboardContent(); > content.putString("Hello from drag source!"); > dragboard.setContent(content); > event.consume(); > }); > > // Set up drag over > dropTarget.setOnDragOver(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > event.acceptTransferModes(TransferMode.COPY); > } > event.consume(); > }); > > // Set up drag entered (visual feedback) > dropTarget.setOnDragEntered(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > } > event.consume(); > }); > > // Set up drag exited (reset visual feedback) > dropTarget.setOnDragExited(event -> { > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > event.consume(); > }); > > // Set up drop > dropTarget.setOnD... > Could this bug be related to [#1936 (comment)](https://github.com/openjdk/jfx/pull/1936#issuecomment-3720278382) ? No, but I understand the reason for the other bug. Already working on a solution for it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2003#issuecomment-3721261402 From mstrauss at openjdk.org Wed Jan 7 23:35:00 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 7 Jan 2026 23:35:00 GMT Subject: Integrated: 8367557: Extended stage seems to hang after drag and drop In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? wrote: > An extended stage seems to hang after a drag and drop operation. Note that in the attached reproducer, the application seems unresponsive until the mouse cursor leaves and re-enters the application window: > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.input.ClipboardContent; > import javafx.scene.input.Dragboard; > import javafx.scene.input.TransferMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.HBox; > import javafx.scene.layout.HeaderBar; > import javafx.stage.Stage; > import javafx.stage.StageStyle; > > public class DragDropTest extends Application { > > @Override > public void start(Stage primaryStage) { > > primaryStage.initStyle(StageStyle.EXTENDED); > > // Create drag source > Label dragSource = new Label("Drag me!"); > dragSource.setStyle("-fx-background-color: lightblue; -fx-padding: 10px"); > > // Create drop target > Label dropTarget = new Label("Drop here!"); > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > > // Set up drag detection > dragSource.setOnDragDetected(event -> { > Dragboard dragboard = dragSource.startDragAndDrop(TransferMode.COPY); > ClipboardContent content = new ClipboardContent(); > content.putString("Hello from drag source!"); > dragboard.setContent(content); > event.consume(); > }); > > // Set up drag over > dropTarget.setOnDragOver(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > event.acceptTransferModes(TransferMode.COPY); > } > event.consume(); > }); > > // Set up drag entered (visual feedback) > dropTarget.setOnDragEntered(event -> { > if (event.getGestureSource() != dropTarget && event.getDragboard().hasString()) { > dropTarget.setStyle("-fx-background-color: lightgreen; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > } > event.consume(); > }); > > // Set up drag exited (reset visual feedback) > dropTarget.setOnDragExited(event -> { > dropTarget.setStyle("-fx-background-color: lightcoral; -fx-padding: 20px; -fx-min-width: 150px; -fx-min-height: 100px;"); > event.consume(); > }); > > // Set up drop > dropTarget.setOnD... This pull request has now been integrated. Changeset: 4a15d099 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/4a15d0996e12ad9d75f0abbbc8832a47341c4341 Stats: 59 lines in 1 file changed: 33 ins; 24 del; 2 mod 8367557: Extended stage seems to hang after drag and drop Reviewed-by: lkostyra, angorya ------------- PR: https://git.openjdk.org/jfx/pull/2003 From mstrauss at openjdk.org Thu Jan 8 01:52:19 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 01:52:19 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: Message-ID: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> > 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree 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 20 additional commits since the last revision: - move-modal message loop - Merge branch 'master' into headerbar-update - update copyright year to 2026 - use native constants - typo - align Linux/Windows behavior when clicking on resize border - documentation - Unspecified HeaderDragType is behind top resize border - documentation - documentation - ... and 10 more: https://git.openjdk.org/jfx/compare/95580e33...7a18278f ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/280d9d24..7a18278f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=14-15 Stats: 818 lines in 78 files changed: 462 ins; 121 del; 235 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 Thu Jan 8 01:55:13 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 01:55:13 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 18:49:58 GMT, Andy Goryachev wrote: > Found a weird issue on Windows that I cannot reproduce on macOS: The reason for this bug was a missing `MOUSE_RELEASED` event on Windows, which I've fixed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3721559185 From mstrauss at openjdk.org Thu Jan 8 01:58:17 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 01:58:17 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 17:18:18 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright year to 2026 > > modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderDragType.java line 118: > >> 116: * @since 26 >> 117: */ >> 118: TRANSPARENT, > > TRANSPARENT* might be confusing, maybe DRAG_TRANSPARENT* or some such? I've considered it, but then again you're probably going to utter the word "drag" at least two times before you get to say "transparent": `HeaderBar.setDragType(..., HeaderDragType.TRANSPARENT)`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2670604938 From duke at openjdk.org Thu Jan 8 10:21:31 2026 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 8 Jan 2026 10:21:31 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v10] In-Reply-To: References: Message-ID: <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com> > This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX. > > # Behavior before > > If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. > > One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore. > > > # Behavior after > > The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged. > > > # Tests > > This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them. > > > # Additional benifits > > This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar. > > > # Review from AWT > > In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it. > > > # Add disable flag? > > We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first. > > > Co-Author: @FlorianKirmaier Pabulaner IV has updated the pull request 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 14 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 - 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 - ... and 4 more: https://git.openjdk.org/jfx/compare/01195054...562a8fcd ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1904/files - new: https://git.openjdk.org/jfx/pull/1904/files/3670c228..562a8fcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=08-09 Stats: 6263 lines in 210 files changed: 4813 ins; 555 del; 895 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 Jan 8 10:53:58 2026 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 8 Jan 2026 10:53:58 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] 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 two additional commits since the last revision: - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1904/files - new: https://git.openjdk.org/jfx/pull/1904/files/562a8fcd..c57554bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1904&range=09-10 Stats: 28 lines in 9 files changed: 20 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1904.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1904/head:pull/1904 PR: https://git.openjdk.org/jfx/pull/1904 From duke at openjdk.org Thu Jan 8 10:54:01 2026 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 8 Jan 2026 10:54:01 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v10] In-Reply-To: <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com> References: <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com> Message-ID: <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com> On Thu, 8 Jan 2026 10:21:31 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 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 > - 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 > - ... and 4 more: https://git.openjdk.org/jfx/compare/faa1af82...562a8fcd So I think I fixed all the major comments. I added a System.exit() to every test, so after pressing the next button, the windows will all close. I also edited the readme, so the user knows what is expected and how to run the tests. If I missed something important for the approval which needs to be addressed right now, please let me know. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3723290837 PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3723297028 From duke at openjdk.org Thu Jan 8 10:54:05 2026 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 8 Jan 2026 10:54:05 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v9] In-Reply-To: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> References: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> Message-ID: On Wed, 7 Jan 2026 19:28:41 GMT, Andy Goryachev wrote: >> 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 > > tests/manual/systemmenu/MacOSSystemMenuJFXPanelSwingFirstTest.java line 61: > >> 59: >> 60: public void test() throws InterruptedException, IOException { >> 61: initSwing(List.of(TEST_MENUS_0, TEST_MENUS_1)); > > It would be nice to have some instructions / acceptance criteria in each test. > Assume the tester knows nothing about the issue. I added it to the readme, since it is basically the same procedure for every test. > tests/manual/systemmenu/MacOSSystemMenuMultiWindowTest.java line 57: > >> 55: new MacOSSystemMenuMultiWindowTest().test(); >> 56: } >> 57: > > I've got this upon exiting via system menu "Quit java" once: > > > Exception in thread "InvokeLaterDispatcher" java.lang.RuntimeException: Main Java thread is detached. > at javafx.graphics at 26-internal/com.sun.glass.ui.mac.MacApplication._submitForLaterInvocation(Native Method) > at javafx.graphics at 26-internal/com.sun.glass.ui.mac.MacApplication.submitForLaterInvocation(MacApplication.java:375) > at javafx.graphics at 26-internal/com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:122) > > > Also, if I just launch it and then immediately select "Quit java" from the system menu, it hangs with a beach ball and requires ctrl-C in the terminal to kill it. The tests are not meant for exiting via the system menu. They are intended to be run, so the user can test it, and then terminate themselves at the end. > tests/manual/systemmenu/MacOSSystemMenuMultiWindowWithSwingFirstTest.java line 55: > >> 53: >> 54: public static void main(String[] args) throws InterruptedException, IOException { >> 55: new MacOSSystemMenuMultiWindowWithSwingFirstTest().test(); > > this test requires selecting SourceLauncher -> Quit java from the system menu twice to close - is this intentional? Same as for the previous comment. > tests/manual/systemmenu/MacOSSystemMenuMultiWindowWithSwingFirstTest.java line 62: > >> 60: initJavaFX(List.of(TEST_MENUS_1, TEST_MENUS_3)); >> 61: >> 62: focusJavaFX(0); > > Minor: noticed that the "Next" button seem to work only once in this and other tests. Is it intentional? For me this test works fine, with the next button doing exactly what it should. > tests/manual/systemmenu/MacOSSystemMenuSingleWindowWithSwingFirstTest.java line 56: > >> 54: >> 55: public static void main(String[] args) throws InterruptedException, IOException { >> 56: new MacOSSystemMenuSingleWindowWithSwingFirstTest().test(); > > this test hangs when fx window is closed first via the close title bar icon, followed by closing the swing window with same method. Again, the tests are intended only for validating the contents of the system menu bar and then pressing next. Everything else is not intended to work. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671834550 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671836778 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671848391 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671840555 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671844236 From duke at openjdk.org Thu Jan 8 10:54:06 2026 From: duke at openjdk.org (Pabulaner IV) Date: Thu, 8 Jan 2026 10:54:06 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v9] In-Reply-To: References: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com> Message-ID: On Wed, 7 Jan 2026 22:40:14 GMT, Martin Fox wrote: >> tests/manual/systemmenu/README.md line 3: >> >>> 1: # Compiling and Running >>> 2: >>> 3: To compile the tests, run the following command: >> >> Actually, separate compile step is not necessary, the test apps run with the following command from within this directory (you do need to run the gradle build first): >> >> >> java --module-path ../../../build/sdk/lib/ --add-modules javafx.controls,javafx.fxml,javafx.swing MacOSSystemMenuJFXPanelSwingFirstTest.java > > Even easier: > > `java @../../../build/run.args MacOSSystemMenuMultiWindowTest.java ` Thanks, very nice and clean solution! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2671849169 From lkostyra at openjdk.org Thu Jan 8 11:27:10 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 8 Jan 2026 11:27:10 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. It's a small change but we'll have to thoroughly test it before integrating. I'll take a look at it, but a second pair of eyes will be needed for verification on Linux. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3723432410 From kcr at openjdk.org Thu Jan 8 12:20:57 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 12:20:57 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: <7Ca4-pKaOoG_jWVDtT_bj-iNwnPCpMbFrlEZBcEzmhE=.5a605455-845c-4fca-a23d-1bd7e15d0e85@github.com> On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. @azvegint Can you take a look at this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3723610992 From kcr at openjdk.org Thu Jan 8 12:23:36 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 12:23:36 GMT Subject: Integrated: 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth wrote: > This PR changes the links to the JBS home page -- https://bugs.openjdk.org/ -- to point to the JBS project page instead: https://bugs.openjdk.org/projects/JDK > > This avoids a potential problem where the JBS home page redirects to the login page for those without a JBS login. This pull request has now been integrated. Changeset: 2d00f978 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/2d00f978b11e9a1d1e29722b273c39fa01388746 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8374567: Reference to "bugs.openjdk.org" sometimes redirects to login page Reviewed-by: iris, angorya ------------- PR: https://git.openjdk.org/jfx/pull/2027 From kcr at openjdk.org Thu Jan 8 12:23:37 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 12:23:37 GMT Subject: Integrated: 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth wrote: > Adds a note to the "Testing" item for PR Authors to make sure that GHA is enabled for their personal fork. There is already a similar recommendation for Reviewers to check that. This pull request has now been integrated. Changeset: c31d0ef3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c31d0ef3761a1421b782a267bcf41d783d78f988 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8374655: Update CONTRIBUTING.md to ask PR authors to enable GHA in their repo Reviewed-by: arapte, mhanl, angorya ------------- PR: https://git.openjdk.org/jfx/pull/2028 From fthevenet at openjdk.org Thu Jan 8 12:33:42 2026 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Thu, 8 Jan 2026 12:33:42 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Thu, 8 Jan 2026 11:24:20 GMT, Lukasz Kostyra wrote: >> Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. >> To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. >> >> Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. >> One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. >> >> GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. >> When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. > > It's a small change but we'll have to thoroughly test it before integrating. I'll take a look at it, but a second pair of eyes will be needed for verification on Linux. Thanks for looking into this, @lukostyra Here's a thing that I noticed during my own testing that might be of interest: I have verified that when running a test app as a standard process, the file chooser dialog resulting from calling `GtkFileChooserNative` is a standard GTK dialog that is identical to the one produced via `GtkFileChooserDialog` (and when running the test through the XDG portal API, the dialog is indeed a "native" dialog that differs depending on when display environment, which is the whole point for this change). There is, however, a visible difference in what is produced by this implementation compared to the previous one in JavaFX: the "Open/Save" and "Cancel" buttons do not show an icon besides the label: GtkFileChooser GtkNativeFileChooser The reason for that is that `GtkFileChooserNative` does not appear to support using `GTK_STOCK_OPEN/CANCEL` that defines both the default (and localized) label and icon for these actions: instead it displays the raw string if passed, e.g. "gtk-cancel". It is perhaps unsurprising since GTK_STOCK_OPEN et al have been deprecated since v3.10[1], while `GtkNativeDialog` was introduced in 3.20. I looked, but couldn't find an alternative way to add the icon in the new implementation (not that I personally think it is a big loss, but ideally this change shouldn't introduce any visual differences when used in the same context). I have, however, verified that passing `NULL` as the buttons' label to use the default does result in properly localized labels when switching languages (a far more important point, IMO). [1] https://docs.gtk.org/gtk3/const.STOCK_OPEN.html ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3723665290 From jvos at openjdk.org Thu Jan 8 12:37:42 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 8 Jan 2026 12:37:42 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. This works as expected. I will have a deeper look though, as there might be edge cases that I'm missing. Also, the comment above related to label/icon needs more investigation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3723679903 From kcr at openjdk.org Thu Jan 8 12:56:31 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 12:56:31 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:53:58 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 All tests now exit for me after presing "Next" the last time. The quick headful CI test I mentioned passed and I see that the GHA run has passed. I think any further improvements to the test can be done in a follow-up issue. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3639277081 From kcr at openjdk.org Thu Jan 8 12:56:34 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 12:56:34 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v10] In-Reply-To: <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com> References: <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com> <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com> Message-ID: On Thu, 8 Jan 2026 10:49:21 GMT, Pabulaner IV wrote: >> Pabulaner IV 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 14 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 >> - 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 >> - ... and 4 more: https://git.openjdk.org/jfx/compare/b8cfff2f...562a8fcd > > If I missed something important for the approval which needs to be addressed right now, please let me know. @pabulaner I see this in your Description: > Co-Author: @FlorianKirmaier Consider crediting Florian with: `/contributor add @FlorianKirmaier`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3723745875 From kizune at openjdk.org Thu Jan 8 16:13:35 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 8 Jan 2026 16:13:35 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:41:25 GMT, Christopher Schnick wrote: >> This is a pretty simple fix for the accessible text of password fields. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Trigger Build Marked as reviewed by kizune (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2020#pullrequestreview-3640154685 From kizune at openjdk.org Thu Jan 8 16:13:37 2026 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 8 Jan 2026 16:13:37 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 17:08:28 GMT, Andy Goryachev wrote: >> I looked into other implementations of this method and they kinda mixed the usage of "" and null. From that I would expect that the end result for the screen reader would be the same. TextInputControl does it the same way > > this question is for @azuev-java mostly. We have several platforms and several screen readers for each, I don't know whether they all treat "" consistently. I looked at all the implementations and tested it on supported platforms and i do not see any problem caused by this inconsistency. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2020#discussion_r2672976886 From angorya at openjdk.org Thu Jan 8 16:16:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 16:16:47 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:53:58 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 Marked as reviewed by angorya (Reviewer). tests/manual/systemmenu/MacOSSystemMenuTestBase.java line 282: > 280: JFrame window = new JFrame(); > 281: > 282: window.setSize(WINDOW_WIDTH, WINDOW_HEIGHT); this line is likely unnecessary since the Scene is sized in L238, but it does not matter much. ------------- PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3640167610 PR Review Comment: https://git.openjdk.org/jfx/pull/1904#discussion_r2672987939 From angorya at openjdk.org Thu Jan 8 16:28:27 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 16:28:27 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v6] In-Reply-To: References: Message-ID: > Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. > > > ### NOTES > > - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) > - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest > > Screenshot 2025-11-17 at 13 43 12 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into 8371067.request.layout - Merge branch 'master' into 8371067.request.layout - Merge branch 'master' into 8371067.request.layout - updated test - Merge branch 'master' into 8371067.request.layout - add text segment - Merge branch 'master' into 8371067.request.layout - test - request layout - test - ... and 1 more: https://git.openjdk.org/jfx/compare/2d00f978...18c42d10 ------------- Changes: https://git.openjdk.org/jfx/pull/1975/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1975&range=05 Stats: 100 lines in 4 files changed: 94 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1975.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975 PR: https://git.openjdk.org/jfx/pull/1975 From angorya at openjdk.org Thu Jan 8 16:32:30 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 16:32:30 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 01:52:19 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > 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 20 additional commits since the last revision: > > - move-modal message loop > - Merge branch 'master' into headerbar-update > - update copyright year to 2026 > - use native constants > - typo > - align Linux/Windows behavior when clicking on resize border > - documentation > - Unspecified HeaderDragType is behind top resize border > - documentation > - documentation > - ... and 10 more: https://git.openjdk.org/jfx/compare/ef4b51bd...7a18278f Are you going to fix https://github.com/openjdk/jfx/pull/1936#issuecomment-3720278382 as part of this PR or in a followup? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3724669465 From angorya at openjdk.org Thu Jan 8 16:32:33 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 16:32:33 GMT Subject: RFR: 8369836: Update HeaderBar API [v15] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 01:55:31 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderDragType.java line 118: >> >>> 116: * @since 26 >>> 117: */ >>> 118: TRANSPARENT, >> >> TRANSPARENT* might be confusing, maybe DRAG_TRANSPARENT* or some such? > > I've considered it, but then again you're probably going to utter the word "drag" at least two times before you get to say "transparent": `HeaderBar.setDragType(..., HeaderDragType.TRANSPARENT)`. good point ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673041189 From angorya at openjdk.org Thu Jan 8 16:32:56 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 16:32:56 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: References: Message-ID: > Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. > > > ### NOTES > > - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) > - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest > > Screenshot 2025-11-17 at 13 43 12 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 2026 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1975/files - new: https://git.openjdk.org/jfx/pull/1975/files/18c42d10..c255d97f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1975&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1975&range=05-06 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1975.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975 PR: https://git.openjdk.org/jfx/pull/1975 From mstrauss at openjdk.org Thu Jan 8 16:38:42 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 16:38:42 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: <_KdIAwAw5lJbuluzIXeE0yBGAhjfh7e6R6OF0TcJVxs=.8742a28f-0e02-47ab-8bc6-5c8d20318df9@github.com> On Thu, 8 Jan 2026 01:52:19 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > 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 20 additional commits since the last revision: > > - move-modal message loop > - Merge branch 'master' into headerbar-update > - update copyright year to 2026 > - use native constants > - typo > - align Linux/Windows behavior when clicking on resize border > - documentation > - Unspecified HeaderDragType is behind top resize border > - documentation > - documentation > - ... and 10 more: https://git.openjdk.org/jfx/compare/bf638d46...7a18278f > Are you going to fix [#1936 (comment)](https://github.com/openjdk/jfx/pull/1936#issuecomment-3720278382) as part of this PR or in a followup? It's already fixed in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1936#issuecomment-3724694009 From angorya at openjdk.org Thu Jan 8 17:13:01 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 17:13:01 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 01:52:19 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > 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 20 additional commits since the last revision: > > - move-modal message loop > - Merge branch 'master' into headerbar-update > - update copyright year to 2026 > - use native constants > - typo > - align Linux/Windows behavior when clicking on resize border > - documentation > - Unspecified HeaderDragType is behind top resize border > - documentation > - documentation > - ... and 10 more: https://git.openjdk.org/jfx/compare/c550559e...7a18278f modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 689: > 687: // We don't consume this message, so it will be handled as usual in HandleViewMouseEvent() > 688: // to generate a normal JavaFX event. Note that HandleViewMouseEvent() calls SetCapture(). > 689: case WM_LBUTTONDOWN: Do we need to handle any other mouse events here (wheel, horizontal scroll, etc)? I do see the horizontal scroll happening in the client area outside of the header bar when I first click and hold the left mouse button inside the header bar text field (i.e. inside a drag event), but this behavior is exhibited elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673180648 From angorya at openjdk.org Thu Jan 8 17:25:55 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 17:25:55 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 01:52:19 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > 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 20 additional commits since the last revision: > > - move-modal message loop > - Merge branch 'master' into headerbar-update > - update copyright year to 2026 > - use native constants > - typo > - align Linux/Windows behavior when clicking on resize border > - documentation > - Unspecified HeaderDragType is behind top resize border > - documentation > - documentation > - ... and 10 more: https://git.openjdk.org/jfx/compare/d8a5d33f...7a18278f looks good now, excellent work! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3640447500 From angorya at openjdk.org Thu Jan 8 18:09:04 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 18:09:04 GMT Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v12] 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 17 additional commits since the last revision: - 2026 - Merge branch '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 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 - ... and 7 more: https://git.openjdk.org/jfx/compare/44391c76...85a2926a ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1773/files - new: https://git.openjdk.org/jfx/pull/1773/files/ee64a8a1..85a2926a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1773&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1773&range=10-11 Stats: 704 lines in 78 files changed: 348 ins; 120 del; 236 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 mstrauss at openjdk.org Thu Jan 8 18:51:53 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 18:51:53 GMT Subject: RFR: 8369836: Update HeaderBar API [v17] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: always consume WM_MOUSEMOVE ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/7a18278f..0707bd6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=16 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=15-16 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 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 Thu Jan 8 18:54:42 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 18:54:42 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 17:09:25 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 20 additional commits since the last revision: >> >> - move-modal message loop >> - Merge branch 'master' into headerbar-update >> - update copyright year to 2026 >> - use native constants >> - typo >> - align Linux/Windows behavior when clicking on resize border >> - documentation >> - Unspecified HeaderDragType is behind top resize border >> - documentation >> - documentation >> - ... and 10 more: https://git.openjdk.org/jfx/compare/fe76b5e9...7a18278f > > modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 689: > >> 687: // We don't consume this message, so it will be handled as usual in HandleViewMouseEvent() >> 688: // to generate a normal JavaFX event. Note that HandleViewMouseEvent() calls SetCapture(). >> 689: case WM_LBUTTONDOWN: > > Do we need to handle any other mouse events here (wheel, horizontal scroll, etc)? > > I do see the horizontal scroll happening in the client area outside of the header bar when I first click and hold the left mouse button inside the header bar text field (i.e. inside a drag event), but this behavior is exhibited elsewhere. You _should_ see mouse events not related to the press-drag-release gesture. However, I've changed a tiny detail: when you press the left mouse button on the title bar and then move the cursor, you'll get a small number of `MOUSE_DRAGGED` events until the cursor leaves the "dead zone" and the move-modal loop starts. Once the move-modal loop has started, you won't receive events related to the window drag gesture. I think that the few drag events at the beginning of a PDR gesture are just noise, therefore I've changed it so that from the perspective of the application, a PDR gesture on the title bar only produces `MOUSE_PRESSED` followed by `MOUSE_RELEASED`, but no drag events in-between. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673496056 From angorya at openjdk.org Thu Jan 8 19:42:00 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 19:42:00 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 18:51:43 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 689: >> >>> 687: // We don't consume this message, so it will be handled as usual in HandleViewMouseEvent() >>> 688: // to generate a normal JavaFX event. Note that HandleViewMouseEvent() calls SetCapture(). >>> 689: case WM_LBUTTONDOWN: >> >> Do we need to handle any other mouse events here (wheel, horizontal scroll, etc)? >> >> I do see the horizontal scroll happening in the client area outside of the header bar when I first click and hold the left mouse button inside the header bar text field (i.e. inside a drag event), but this behavior is exhibited elsewhere. > > You _should_ see mouse events not related to the press-drag-release gesture. > > However, I've changed a tiny detail: when you press the left mouse button on the title bar and then move the cursor, you'll get a small number of `MOUSE_DRAGGED` events until the cursor leaves the "dead zone" and the move-modal loop starts. Once the move-modal loop has started, you won't receive events related to the window drag gesture. > > I think that the few drag events at the beginning of a PDR gesture are just noise, therefore I've changed it so that from the perspective of the application, a PDR gesture on the title bar only produces `MOUSE_PRESSED` followed by `MOUSE_RELEASED`, but no drag events in-between. Could it have any impact on DnD to/from the header bar? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673641408 From mstrauss at openjdk.org Thu Jan 8 19:56:34 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 19:56:34 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: On Thu, 8 Jan 2026 19:38:42 GMT, Andy Goryachev wrote: >> You _should_ see mouse events not related to the press-drag-release gesture. >> >> However, I've changed a tiny detail: when you press the left mouse button on the title bar and then move the cursor, you'll get a small number of `MOUSE_DRAGGED` events until the cursor leaves the "dead zone" and the move-modal loop starts. Once the move-modal loop has started, you won't receive events related to the window drag gesture. >> >> I think that the few drag events at the beginning of a PDR gesture are just noise, therefore I've changed it so that from the perspective of the application, a PDR gesture on the title bar only produces `MOUSE_PRESSED` followed by `MOUSE_RELEASED`, but no drag events in-between. > > Could it have any impact on DnD to/from the header bar? I've tested this, and you can drop something _onto_ a header bar, but you can't do the oppsite and drag-and-drop the header bar itself. That seems obvious, as any attempt to press-and-drag the header bar will just move the window instead of starting a DnD operation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673681732 From angorya at openjdk.org Thu Jan 8 20:01:56 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 20:01:56 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> Message-ID: <-kkJ9nrHZp7koSMf9mq9JnDC4MkunmzQijvcJvCri2c=.ad613b7c-16a1-470d-b395-d3a6d1296d4a@github.com> On Thu, 8 Jan 2026 19:53:19 GMT, Michael Strau? wrote: >> Could it have any impact on DnD to/from the header bar? > > I've tested this, and you can drop something _onto_ a header bar, but you can't do the oppsite and drag-and-drop the header bar itself. That seems obvious, as any attempt to press-and-drag the header bar will just move the window instead of starting a DnD operation. I was thinking of a scenario where DnD is used to rearrange items within the header bar, or DnD between the header bar and some palette-like UI, to customize the header bar. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673698515 From mstrauss at openjdk.org Thu Jan 8 20:12:51 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 20:12:51 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: <-kkJ9nrHZp7koSMf9mq9JnDC4MkunmzQijvcJvCri2c=.ad613b7c-16a1-470d-b395-d3a6d1296d4a@github.com> References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> <-kkJ9nrHZp7koSMf9mq9JnDC4MkunmzQijvcJvCri2c=.ad613b7c-16a1-470d-b395-d3a6d1296d4a@github.com> Message-ID: On Thu, 8 Jan 2026 19:59:38 GMT, Andy Goryachev wrote: >> I've tested this, and you can drop something _onto_ a header bar, but you can't do the oppsite and drag-and-drop the header bar itself. That seems obvious, as any attempt to press-and-drag the header bar will just move the window instead of starting a DnD operation. > > I was thinking of a scenario where DnD is used to rearrange items within the header bar, or DnD between the header bar and some palette-like UI, to customize the header bar. This works just as before. All of the code in `GlassWindow::HandleCaptionMouseEvents` is only ever relevant if you start the PDR gesture by clicking on a draggable area of the header bar. If you instead click on an interactive part (like a rearrangable button bar or something), the `m_caption.tracking` flag will not be set, and the entire method is a NOP. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673719551 From mstrauss at openjdk.org Thu Jan 8 20:12:52 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 20:12:52 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> <-kkJ9nrHZp7koSMf9mq9JnDC4MkunmzQijvcJvCri2c=.ad613b7c-16a1-470d-b395-d3a6d1296d4a@github.com> Message-ID: On Thu, 8 Jan 2026 20:06:54 GMT, Michael Strau? wrote: >> I was thinking of a scenario where DnD is used to rearrange items within the header bar, or DnD between the header bar and some palette-like UI, to customize the header bar. > > This works just as before. All of the code in `GlassWindow::HandleCaptionMouseEvents` is only ever relevant if you start the PDR gesture by clicking on a draggable area of the header bar. If you instead click on an interactive part (like a rearrangable button bar or something), the `m_caption.tracking` flag will not be set, and the entire method is a NOP. If you make the mistake of marking an interactive node on the header bar as `DRAGGABLE`, then you still won't be able to DnD this node, as the only events you'll ever receive are `MOUSE_PRESSED` and `MOUSE_RELEASED`, but no intermediate `MOUSE_DRAGGED`. The move-modal loop that moves the window will eat all the intermediate events. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673729440 From mstrauss at openjdk.org Thu Jan 8 20:20:33 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 20:20:33 GMT Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v12] In-Reply-To: References: Message-ID: <6ogMDcx7nyD_W35MBPyzzw5GnYjxhKEmI3K5UaLGqXU=.128ba763-c883-4aab-8bd6-4009d4fe914b@github.com> On Thu, 8 Jan 2026 18:09:04 GMT, Andy Goryachev wrote: >> Tries to address the mystery of missing graphic in the TabPane overflow menu. >> >> ### Summary of Changes >> >> - minor `TabPaneSkin` constructor javadoc clarification >> - added the property >> - changed popup menu to be created on demand >> - removing adding the popup reference to the `TabHeaderSkin` properties (I think it was done for testing purposes, I could not find any references to it in the code) >> >> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java >> >> # Overflow Menu Graphic Property in the TabPaneSkin >> >> Andy Goryachev >> >> >> >> >> ## Summary >> >> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin >> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic. >> >> >> >> ## Goals >> >> The goals of this proposal are: >> >> - to allow the application developers to customize the overflow menu items' graphic >> - retain the backward compatibility with the existing application code >> - clarify the behavior of the skin when the property is null (i.e. the current behavior) >> >> >> >> ## Non-Goals >> >> The following are not the goals of this proposal: >> >> - disable the overflow menu >> - configure overflow menu graphic property via CSS >> - add this property to the `TabPane` control itself >> >> >> >> ## Motivation >> >> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than >> an `ImageView` or `Label` with an `ImageView`. >> >> This limitation makes it impossible for the application developer to use other graphic Nodes, >> such as `Path` or `Canvas`, or in fact any other types. The situation becomes even more egregious >> when the tabs in the `TabPane` have no text. >> >> Example: >> >> >> public class TabPaneGraphicFactoryExample { >> public void example() { >> Tab tab1 = new Tab("Tab1"); >> tab1.setGraphic(createGraphic(tab1)); >> >> Tab tab2 = new Tab("Tab2"); >> tab2.setGraphic(createGraphic(tab2)); >> >> TabPane tabPane = new TabPane(); >> tabPane.getTabs().addAll(tab1, tab2); >> >> TabPaneSkin skin = new TabPaneSkin(tabPane); >> // set overflow menu factory with the same method as was used to create the tabs >> skin.setMenuGraphicFactory(this::createGraphic); >> tabPane.setSkin(skin); >> } >> >> // creates graphic Nodes for tabs as well as the overflow menu > ... > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - 2026 > - Merge branch '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 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 > - ... and 7 more: https://git.openjdk.org/jfx/compare/6566d493...85a2926a > > But, can we fix on a behavior that if a graphic is set on a tab, then the same graphic would be used in overflow menu and a graphic from menuGraphicFactory will be neglected ? > > Good question! > > We can't, if the graphic set on a tab is some sort of a custom `Node` and not the usual `ImageView` or `Label`. In this case, we can't easily clone that custom graphic such that it appears in the tab **and** in the overflow menu. > > Ideally, the solution would be to replace setting the graphic on a tab with setting a Supplier. This way the graphic can be supplied multiple times as needed, but it would be a breaking change and something that is not needed in 99.9% of the cases. WPF has [VisualBrush](https://learn.microsoft.com/en-us/dotnet/api/system.windows.media.visualbrush?view=windowsdesktop-10.0), which is like a JavaFX `Paint` that, instead of filling a shape with a color, fills it with the rendered representation of another node. Maybe there's something similar that could be done for JavaFX, which would make it easier to solve problems where a node in one part of the scene graph should be projected into another part of the scene graph. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-3725605021 From angorya at openjdk.org Thu Jan 8 20:30:11 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 20:30:11 GMT Subject: RFR: 8369836: Update HeaderBar API [v17] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 18:51:53 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > always consume WM_MOUSEMOVE Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3641159739 From angorya at openjdk.org Thu Jan 8 20:30:12 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 20:30:12 GMT Subject: RFR: 8369836: Update HeaderBar API [v16] In-Reply-To: References: <3NH3eJ35YcJQ8iFHCHyT1PoDkVMBt7wJ4LbQIEl1d5A=.b8ee5250-7a50-4ded-8302-7b4a6b642ff0@github.com> <-kkJ9nrHZp7koSMf9mq9JnDC4MkunmzQijvcJvCri2c=.ad613b7c-16a1-470d-b395-d3a6d1296d4a@github.com> Message-ID: On Thu, 8 Jan 2026 20:09:41 GMT, Michael Strau? wrote: >> This works just as before. All of the code in `GlassWindow::HandleCaptionMouseEvents` is only ever relevant if you start the PDR gesture by clicking on a draggable area of the header bar. If you instead click on an interactive part (like a rearrangable button bar or something), the `m_caption.tracking` flag will not be set, and the entire method is a NOP. > > If you make the mistake of marking an interactive node on the header bar as `DRAGGABLE`, then you still won't be able to DnD this node, as the only events you'll ever receive are `MOUSE_PRESSED` and `MOUSE_RELEASED`, but no intermediate `MOUSE_DRAGGED`. The move-modal loop that moves the window will eat all the intermediate events. yes, the DnD is unaffected. thanks for clarification! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1936#discussion_r2673787147 From mfox at openjdk.org Thu Jan 8 20:32:22 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 8 Jan 2026 20:32:22 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:53:58 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'll approve this as-is. I'd still like to see some cleanup and expansion of the tests (I had to test the "all windows iconified" cases separately) but that can be done later. I'll enter a bug for that sometime next week. ------------- Marked as reviewed by mfox (Committer). PR Review: https://git.openjdk.org/jfx/pull/1904#pullrequestreview-3641172338 From angorya at openjdk.org Thu Jan 8 20:45:29 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 20:45:29 GMT Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v12] In-Reply-To: <6ogMDcx7nyD_W35MBPyzzw5GnYjxhKEmI3K5UaLGqXU=.128ba763-c883-4aab-8bd6-4009d4fe914b@github.com> References: <6ogMDcx7nyD_W35MBPyzzw5GnYjxhKEmI3K5UaLGqXU=.128ba763-c883-4aab-8bd6-4009d4fe914b@github.com> Message-ID: On Thu, 8 Jan 2026 20:18:30 GMT, Michael Strau? wrote: > rendered representation of another node I think this idea might be counter-productive: the app may want to style the overflow icons differently (different size, for example, or using different CSS selectors). The original developers just did not consider scenarios that go beyond commonly used labels or images. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1773#issuecomment-3725708577 From mstrauss at openjdk.org Thu Jan 8 23:28:01 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 8 Jan 2026 23:28:01 GMT Subject: RFR: 8358450: Viewport characteristics media features [v19] In-Reply-To: References: Message-ID: <_oLDVUcjEFFVzmP31N0vsX9AsMlskCAUDsFT7LWLfRE=.e6fbfedd-559e-4ecd-ab37-b019113a9690@github.com> > Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics): > * `width` > * `height` > * `aspect-ratio`: width / height > * `orientation`: `portrait`, `landscape` > * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX) > > Here's a small example how the new media features can be used: > > @Override > public void start(Stage stage) { > var button = new Button("Toggle full-screen"); > button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); > var label = new Label(); > var root = new BorderPane(button, null, null, label, null); > var scene = new Scene(root, 650, 200); > BorderPane.setAlignment(label, Pos.CENTER); > label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > @media (max-width: 500) { > .button { > -fx-background-color: red; > } > } > > @media (600 < width <= 700) { > .button { > -fx-background-color: green; > } > } > > @media (min-width: 800) { > .button { > -fx-background-color: yellow; > } > } > > @media (display-mode: fullscreen) { > .button { > -fx-background-color: black !important; > } > } > """.getBytes(StandardCharsets.UTF_8))); > > stage.initStyle(StageStyle.DECORATED); > stage.setScene(scene); > stage.show(); > } Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1844/files - new: https://git.openjdk.org/jfx/pull/1844/files/0fc311f2..a1699311 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=18 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1844.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844 PR: https://git.openjdk.org/jfx/pull/1844 From angorya at openjdk.org Thu Jan 8 23:28:02 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 8 Jan 2026 23:28:02 GMT Subject: RFR: 8358450: Viewport characteristics media features [v19] In-Reply-To: <_oLDVUcjEFFVzmP31N0vsX9AsMlskCAUDsFT7LWLfRE=.e6fbfedd-559e-4ecd-ab37-b019113a9690@github.com> References: <_oLDVUcjEFFVzmP31N0vsX9AsMlskCAUDsFT7LWLfRE=.e6fbfedd-559e-4ecd-ab37-b019113a9690@github.com> Message-ID: <0Wxt-yl1e6H6LAPO8adS9qivsX8QQDbv3CN58tS67zU=.fcf1b07b-50d3-463d-a6a0-7995b7e28281@github.com> On Thu, 8 Jan 2026 23:23:15 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > typo Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3641704105 From kcr at openjdk.org Thu Jan 8 23:43:39 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 8 Jan 2026 23:43:39 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v10] In-Reply-To: <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com> References: <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com> <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com> Message-ID: On Thu, 8 Jan 2026 10:49:21 GMT, Pabulaner IV wrote: >> Pabulaner IV 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 14 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 >> - 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 >> - ... and 4 more: https://git.openjdk.org/jfx/compare/d8bec92f...562a8fcd > > If I missed something important for the approval which needs to be addressed right now, please let me know. @pabulaner This is now ready to integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3726391163 From zelmidaoui at openjdk.org Fri Jan 9 01:31:42 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Fri, 9 Jan 2026 01:31:42 GMT Subject: RFR: 8371070: RichParagraph enhancements [v9] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 23:29:19 GMT, Andy Goryachev wrote: >> This PR addresses the user feedback: >> >> In RichParagraph you have a note to make getSegments() public. It would be helpful if it was. >> >> >> The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch. >> >> This is done in two parts: >> >> 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method >> >> >> protected RichParagraph.Builder prepareParagraph(int index) >> >> >> 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes: >> >> - getSegmentCount() >> - getSegment(int index) >> >> NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - prepare paragraph > - Merge branch 'master' into 8371070.enhance > - javadoc > - cleanup > - Merge branch 'master' into 8366198.rbuilder > - rich paragraph builder api > - Merge branch 'master' into 8371070.enhance > - npe > - merge > - Merge branch 'master' into 8371070.enhance > - ... and 4 more: https://git.openjdk.org/jfx/compare/b39e1faa...dd3ec196 LTGM , tested with JavaFx app and with the added tests it works fine ------------- Marked as reviewed by zelmidaoui (Committer). PR Review: https://git.openjdk.org/jfx/pull/1966#pullrequestreview-3642000769 From mstrauss at openjdk.org Fri Jan 9 02:51:10 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 02:51:10 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] 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) > > Here's a small example how the new media features can be used: > > @Override > public void start(Stage stage) { > var button = new Button("Toggle full-screen"); > button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); > var label = new Label(); > var root = new BorderPane(button, null, null, label, null); > var scene = new Scene(root, 650, 200); > BorderPane.setAlignment(label, Pos.CENTER); > label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > @media (max-width: 500) { > .button { > -fx-background-color: red; > } > } > > @media (600 < width <= 700) { > .button { > -fx-background-color: green; > } > } > > @media (min-width: 800) { > .button { > -fx-background-color: yellow; > } > } > > @media (display-mode: fullscreen) { > .button { > -fx-background-color: black !important; > } > } > """.getBytes(StandardCharsets.UTF_8))); > > stage.initStyle(StageStyle.DECORATED); > stage.setScene(scene); > stage.show(); > } Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1844/files - new: https://git.openjdk.org/jfx/pull/1844/files/a1699311..e08227ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=18-19 Stats: 38 lines in 37 files changed: 0 ins; 1 del; 37 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 duke at openjdk.org Fri Jan 9 08:29:12 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 08:29:12 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:53:58 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 @pabulaner Your change (at version c57554bb47610929462c897fa28d3b70e1b8244d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3727740733 From mmack at openjdk.org Fri Jan 9 10:34:58 2026 From: mmack at openjdk.org (Markus Mack) Date: Fri, 9 Jan 2026 10:34:58 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 02:51:10 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years I reviewed this PR's code and left some minor comments. The largest part is an implementation of complex media query expressions, which looks very solid and well-maintainable. Manual testing on Windows 11 looks good as well as long as there are no CSS transitions. In combination with CSS transitions I see some irregularities, e.g. consider this in a resizable window with two buttons: .button { transition: -fx-scale-x 2s; } @media (width > 300px) { .button { -fx-scale-x: 2; } } When horizontally resizing the window around the width threshold, sometimes the transition jumps or even affects one of the buttons differently than the other. Is such a configuration supposed to be supported? modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 880: > 878: operators and two values. For example:
> 879: > 880: (400px >= width >= 600px)
This should be `(400px <= width <= 600px)` modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuery.java line 55: > 53: * @return the context awareness flags > 54: */ > 55: int getContextAwareness(); Have you considered using an EnumSet here for stronger typing? ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3643179694 PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2675525845 PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2675527995 From mstrauss at openjdk.org Fri Jan 9 13:59:32 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 13:59:32 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:48:30 GMT, Markus Mack wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/media/MediaQuery.java line 55: > >> 53: * @return the context awareness flags >> 54: */ >> 55: int getContextAwareness(); > > Have you considered using an EnumSet here for stronger typing? Yes, it also was an `EnumSet` in an earlier revision. However, these expressions are immutable, which an `EnumSet` is not. So I'd have to wrap the enum set in an unmodifiable set, which adds indirections on a hot path (or accept that these structures are not truly immutable). A primitive `int` is immutable by nature... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676284528 From mstrauss at openjdk.org Fri Jan 9 14:05:28 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 14:05:28 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 09:47:46 GMT, Markus Mack wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright years > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 880: > >> 878: operators and two values. For example:
>> 879: >> 880: (400px >= width >= 600px)
> > This should be `(400px <= width <= 600px)` @kevinrushforth This is a typo that affects an already-approved CSR, but fixing it doesn't meaningfully change the specification. Given that I'd like to get this PR in for JFX 26, how do we continue here? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676302608 From duke at openjdk.org Fri Jan 9 14:10:11 2026 From: duke at openjdk.org (Pabulaner IV) Date: Fri, 9 Jan 2026 14:10:11 GMT Subject: Integrated: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:20:10 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 This pull request has now been integrated. Changeset: 5fbd5e60 Author: pabulaner Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/5fbd5e60ed242210a32e3f223d4d917da91b2caa Stats: 1185 lines in 15 files changed: 1170 ins; 12 del; 3 mod 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX Co-authored-by: Florian Kirmaier Reviewed-by: kcr, angorya, mfox ------------- PR: https://git.openjdk.org/jfx/pull/1904 From mstrauss at openjdk.org Fri Jan 9 14:13:22 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 14:13:22 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: <-fS1EL4yc03rQC72JGWx49ZkuKJ0Dl6PGfKqXkxZC5w=.60b19210-d090-4e36-b340-76dd165c5b34@github.com> On Fri, 9 Jan 2026 10:30:40 GMT, Markus Mack wrote: > When horizontally resizing the window around the width threshold, sometimes the transition jumps or even affects one of the buttons differently than the other. Is such a configuration supposed to be supported? It looks like it should be supported. I'll file a follow-up ticket to track this bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3729059327 From mmack at openjdk.org Fri Jan 9 14:28:41 2026 From: mmack at openjdk.org (Markus Mack) Date: Fri, 9 Jan 2026 14:28:41 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 02:51:10 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Marked as reviewed by mmack (Author). ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3644141565 From angorya at openjdk.org Fri Jan 9 15:22:30 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 15:22:30 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 02:51:10 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3644377176 From angorya at openjdk.org Fri Jan 9 15:25:05 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 15:25:05 GMT Subject: RFR: 8371070: RichParagraph enhancements [v9] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 23:29:19 GMT, Andy Goryachev wrote: >> This PR addresses the user feedback: >> >> In RichParagraph you have a note to make getSegments() public. It would be helpful if it was. >> >> >> The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch. >> >> This is done in two parts: >> >> 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method >> >> >> protected RichParagraph.Builder prepareParagraph(int index) >> >> >> 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes: >> >> - getSegmentCount() >> - getSegment(int index) >> >> NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - prepare paragraph > - Merge branch 'master' into 8371070.enhance > - javadoc > - cleanup > - Merge branch 'master' into 8366198.rbuilder > - rich paragraph builder api > - Merge branch 'master' into 8371070.enhance > - npe > - merge > - Merge branch 'master' into 8371070.enhance > - ... and 4 more: https://git.openjdk.org/jfx/compare/b39e1faa...dd3ec196 Thank you all! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1966#issuecomment-3729357903 From angorya at openjdk.org Fri Jan 9 15:29:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 15:29:28 GMT Subject: Integrated: 8371070: RichParagraph enhancements In-Reply-To: References: Message-ID: <-7Ggi2s3szB5KKgAW_wrRU_U0i_1Sr0e6nri8iN5Hjs=.1ae09e21-db97-4cce-8dc8-374f82915e21@github.com> On Fri, 7 Nov 2025 20:08:15 GMT, Andy Goryachev wrote: > This PR addresses the user feedback: > > In RichParagraph you have a note to make getSegments() public. It would be helpful if it was. > > > The problem being solved here is to allow the developers to easily add functionality to the existing `RichTextModel` (and its storage implementation) without creating a new model from scratch. > > This is done in two parts: > > 1. Allowing the custom model to alter the paragraph by giving access to its Builder via a new protected method > > > protected RichParagraph.Builder prepareParagraph(int index) > > > 2. Adding two methods that give access to the segments in the `RichParagraph` and `RichParagraph.Builder` classes: > > - getSegmentCount() > - getSegment(int index) > > NOTE: Even though returning an (immutable) List might be considered "more useful", doing so would necessitate creating a copy - something I do want to avoid. This pull request has now been integrated. Changeset: 04399ee4 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/04399ee4c52e7ff05615aa00902a9bd5bf717c4f Stats: 275 lines in 8 files changed: 198 ins; 43 del; 34 mod 8371070: RichParagraph enhancements Reviewed-by: kcr, zelmidaoui ------------- PR: https://git.openjdk.org/jfx/pull/1966 From angorya at openjdk.org Fri Jan 9 15:33:15 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 15:33:15 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:32:56 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 2026 Could you please review this PR? Reviewers: @kevinrushforth @Ziad-Mid ------------- PR Comment: https://git.openjdk.org/jfx/pull/1975#issuecomment-3729396890 From duke at openjdk.org Fri Jan 9 15:40:52 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 9 Jan 2026 15:40:52 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:41:25 GMT, Christopher Schnick wrote: >> This is a pretty simple fix for the accessible text of password fields. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Trigger Build This is ready now, I ran the GHA builds ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3729425760 From kcr at openjdk.org Fri Jan 9 15:55:54 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jan 2026 15:55:54 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: Message-ID: <2lYGTmu1vYYakk1_nHToj3nrOHjZqq4cVtLYHG3XCGc=.5dbe4b3c-7b2d-419f-8aaf-5d5d679f9fd7@github.com> On Fri, 9 Jan 2026 14:01:59 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 880: >> >>> 878: operators and two values. For example:
>>> 879: >>> 880: (400px >= width >= 600px)
>> >> This should be `(400px <= width <= 600px)` > > @kevinrushforth This is a typo that affects an already-approved CSR, but fixing it doesn't meaningfully change the specification. Given that I'd like to get this PR in for JFX 26, how do we continue here? Since it is not a material change that would, by itself, need a CSR, go ahead and proceed with the integration. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676703782 From kcr at openjdk.org Fri Jan 9 16:00:38 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jan 2026 16:00:38 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: <2lYGTmu1vYYakk1_nHToj3nrOHjZqq4cVtLYHG3XCGc=.5dbe4b3c-7b2d-419f-8aaf-5d5d679f9fd7@github.com> References: <2lYGTmu1vYYakk1_nHToj3nrOHjZqq4cVtLYHG3XCGc=.5dbe4b3c-7b2d-419f-8aaf-5d5d679f9fd7@github.com> Message-ID: On Fri, 9 Jan 2026 15:53:35 GMT, Kevin Rushforth wrote: >> @kevinrushforth This is a typo that affects an already-approved CSR, but fixing it doesn't meaningfully change the specification. Given that I'd like to get this PR in for JFX 26, how do we continue here? > > Since it is not a material change that would, by itself, need a CSR, go ahead and proceed with the integration. To clarify a bit, you can fix this now if you like (it will require a re-review of the PR) or file a follow-up bug and fix it. It's probably easiest to fix it now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676714976 From kcr at openjdk.org Fri Jan 9 16:00:39 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jan 2026 16:00:39 GMT Subject: RFR: 8358450: Viewport characteristics media features [v20] In-Reply-To: References: <2lYGTmu1vYYakk1_nHToj3nrOHjZqq4cVtLYHG3XCGc=.5dbe4b3c-7b2d-419f-8aaf-5d5d679f9fd7@github.com> Message-ID: On Fri, 9 Jan 2026 15:56:43 GMT, Kevin Rushforth wrote: >> Since it is not a material change that would, by itself, need a CSR, go ahead and proceed with the integration. > > To clarify a bit, you can fix this now if you like (it will require a re-review of the PR) or file a follow-up bug and fix it. It's probably easiest to fix it now. If you do fix it now, I recommend adding a comment to the CSR with the diff. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676719155 From kcr at openjdk.org Fri Jan 9 16:03:34 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jan 2026 16:03:34 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 15:37:14 GMT, Christopher Schnick wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Trigger Build > > This is ready now, I ran the GHA builds @crschnick Since this is now ready, the next step is for you to issue the `/integrate` command. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3729518905 From duke at openjdk.org Fri Jan 9 16:05:21 2026 From: duke at openjdk.org (Pabulaner IV) Date: Fri, 9 Jan 2026 16:05:21 GMT Subject: RFR: 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX [v11] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 10:53:58 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, much appreciated! (Both for the final integration and the very helpful feedback) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1904#issuecomment-3729539480 From mstrauss at openjdk.org Fri Jan 9 16:06:46 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 16:06:46 GMT Subject: RFR: 8358450: Viewport characteristics media features [v21] 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) > > Here's a small example how the new media features can be used: > > @Override > public void start(Stage stage) { > var button = new Button("Toggle full-screen"); > button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); > var label = new Label(); > var root = new BorderPane(button, null, null, label, null); > var scene = new Scene(root, 650, 200); > BorderPane.setAlignment(label, Pos.CENTER); > label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > @media (max-width: 500) { > .button { > -fx-background-color: red; > } > } > > @media (600 < width <= 700) { > .button { > -fx-background-color: green; > } > } > > @media (min-width: 800) { > .button { > -fx-background-color: yellow; > } > } > > @media (display-mode: fullscreen) { > .button { > -fx-background-color: black !important; > } > } > """.getBytes(StandardCharsets.UTF_8))); > > stage.initStyle(StageStyle.DECORATED); > stage.setScene(scene); > stage.show(); > } Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1844/files - new: https://git.openjdk.org/jfx/pull/1844/files/e08227ca..f0f7747f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1844.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844 PR: https://git.openjdk.org/jfx/pull/1844 From angorya at openjdk.org Fri Jan 9 16:16:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 16:16:39 GMT Subject: RFR: 8358450: Viewport characteristics media features [v21] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:06:46 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > typo Marked as reviewed by angorya (Reviewer). modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 880: > 878: operators and two values. For example:
> 879: > 880: (600px >= width >= 400px)
it's probably customary to go from small value to large `400 >= width >= 600` ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3644614551 PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676765708 From mstrauss at openjdk.org Fri Jan 9 16:16:41 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 16:16:41 GMT Subject: RFR: 8358450: Viewport characteristics media features [v21] In-Reply-To: References: Message-ID: <6n6VXhnO04-BdG4D4PeX-1QoPUQqh3jI2BnyA2A9_YU=.a28d58f7-69fe-4ef2-9cb7-23e3ac0702ba@github.com> On Fri, 9 Jan 2026 16:10:09 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> typo > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 880: > >> 878: operators and two values. For example:
>> 879: >> 880: (600px >= width >= 400px)
> > it's probably customary to go from small value to large > `400 >= width >= 600` Yes, but I think it's better to show both versions here, since otherwise people might think that only one form is supported. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1844#discussion_r2676769996 From duke at openjdk.org Fri Jan 9 16:17:04 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 9 Jan 2026 16:17:04 GMT Subject: Integrated: 8374329: PasswordField ignores custom accessible text In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 09:01:49 GMT, Christopher Schnick wrote: > This is a pretty simple fix for the accessible text of password fields. This pull request has now been integrated. Changeset: 06fbd665 Author: Christopher Schnick Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/06fbd665a3e6bf531ea1d393a66d0b2046dc9609 Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod 8374329: PasswordField ignores custom accessible text Reviewed-by: angorya, kizune ------------- PR: https://git.openjdk.org/jfx/pull/2020 From duke at openjdk.org Fri Jan 9 16:27:32 2026 From: duke at openjdk.org (Jurgen) Date: Fri, 9 Jan 2026 16:27:32 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: References: Message-ID: <4Da2iL24dN4K3LoXzibKqfyDxegZhLPea_z75-tBFg4=.987ebe40-c0c7-4780-8cc0-94a354deeca9@github.com> On Thu, 8 Jan 2026 16:32:56 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 2026 lgtm ------------- Marked as reviewed by Jugen at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jfx/pull/1975#pullrequestreview-3644666725 From mmack at openjdk.org Fri Jan 9 16:29:58 2026 From: mmack at openjdk.org (Markus Mack) Date: Fri, 9 Jan 2026 16:29:58 GMT Subject: RFR: 8358450: Viewport characteristics media features [v21] In-Reply-To: References: Message-ID: <_X_b0DmaLmMGxJe-OZG8AiT5S2_7fnowGZiQytAY-kY=.2c0bd4f1-47dd-493d-bd17-366431a0f3e7@github.com> On Fri, 9 Jan 2026 16:06:46 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) >> >> Here's a small example how the new media features can be used: >> >> @Override >> public void start(Stage stage) { >> var button = new Button("Toggle full-screen"); >> button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); >> var label = new Label(); >> var root = new BorderPane(button, null, null, label, null); >> var scene = new Scene(root, 650, 200); >> BorderPane.setAlignment(label, Pos.CENTER); >> label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> @media (max-width: 500) { >> .button { >> -fx-background-color: red; >> } >> } >> >> @media (600 < width <= 700) { >> .button { >> -fx-background-color: green; >> } >> } >> >> @media (min-width: 800) { >> .button { >> -fx-background-color: yellow; >> } >> } >> >> @media (display-mode: fullscreen) { >> .button { >> -fx-background-color: black !important; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> >> stage.initStyle(StageStyle.DECORATED); >> stage.setScene(scene); >> stage.show(); >> } > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > typo Marked as reviewed by mmack (Author). ------------- PR Review: https://git.openjdk.org/jfx/pull/1844#pullrequestreview-3644677532 From duke at openjdk.org Fri Jan 9 16:29:56 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 9 Jan 2026 16:29:56 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:41:25 GMT, Christopher Schnick wrote: >> This is a pretty simple fix for the accessible text of password fields. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Trigger Build By the way, how does one get an account for the bugs.openjdk.org site? I would be interested in creating a few more small tickets for fixes like this that should be relatively straightforward. I would also submit a PR for them. Going through the public bug report form and the review period is quite tedious for things like this ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3729646025 From angorya at openjdk.org Fri Jan 9 16:29:58 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 16:29:58 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 16:20:01 GMT, Christopher Schnick wrote: > how does one get an account for the bugs.openjdk.org site? See here: https://github.com/openjdk/jfx/pull/2016#issuecomment-3683132075 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3729672323 From mstrauss at openjdk.org Fri Jan 9 16:35:39 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 16:35:39 GMT Subject: RFR: 8358450: Viewport characteristics media features [v18] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 22:34:08 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> if parser exception is thrown, include verbatim user value in the message, not lower-cased version > > for other reviewers: I've updated the monkey tester's CSS Playground to apply the stylesheets to the newly created windows. Thanks @andy-goryachev-oracle and @drmarmac for the reviews! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1844#issuecomment-3729703099 From mstrauss at openjdk.org Fri Jan 9 16:35:41 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 9 Jan 2026 16:35:41 GMT Subject: Integrated: 8358450: Viewport characteristics media features In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 05:18:31 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) > > Here's a small example how the new media features can be used: > > @Override > public void start(Stage stage) { > var button = new Button("Toggle full-screen"); > button.setOnAction(_ -> stage.setFullScreen(!stage.isFullScreen())); > var label = new Label(); > var root = new BorderPane(button, null, null, label, null); > var scene = new Scene(root, 650, 200); > BorderPane.setAlignment(label, Pos.CENTER); > label.textProperty().bind(scene.widthProperty().map(v -> String.format("Width: %.2f", v.doubleValue()))); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > @media (max-width: 500) { > .button { > -fx-background-color: red; > } > } > > @media (600 < width <= 700) { > .button { > -fx-background-color: green; > } > } > > @media (min-width: 800) { > .button { > -fx-background-color: yellow; > } > } > > @media (display-mode: fullscreen) { > .button { > -fx-background-color: black !important; > } > } > """.getBytes(StandardCharsets.UTF_8))); > > stage.initStyle(StageStyle.DECORATED); > stage.setScene(scene); > stage.show(); > } This pull request has now been integrated. Changeset: f7b563c7 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/f7b563c70fb73f710aa78bc3a1ce75baa7790150 Stats: 2837 lines in 39 files changed: 2277 ins; 205 del; 355 mod 8358450: Viewport characteristics media features 8368508: Missing info in JavaFX CSS Reference Guide Reviewed-by: angorya, mmack ------------- PR: https://git.openjdk.org/jfx/pull/1844 From duke at openjdk.org Fri Jan 9 16:55:15 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 9 Jan 2026 16:55:15 GMT Subject: RFR: 8374329: PasswordField ignores custom accessible text [v4] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:41:25 GMT, Christopher Schnick wrote: >> This is a pretty simple fix for the accessible text of password fields. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Trigger Build I can't find any details on that page, but I found this which explains it: https://openjdk.org/guide/#becoming-an-author ------------- PR Comment: https://git.openjdk.org/jfx/pull/2020#issuecomment-3729777990 From martinfox656 at gmail.com Fri Jan 9 18:35:52 2026 From: martinfox656 at gmail.com (Martin Fox) Date: Fri, 9 Jan 2026 10:35:52 -0800 Subject: Default event handlers In-Reply-To: References: Message-ID: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> Default handlers might make sense for Control (it?s reasonable to assume that a behavior or skin may install handlers) but the rest of the system avoids using handlers and instead relies on custom dispatchers. It seems wrong to add calls for registering default handlers on Scene and Window when they make a point of not using handlers to begin with. Could we restrict this to Control? Or at the very least Node? If this was restricted to Control would we still make the call for registering a default handler public? For existing controls outside developers should only register primary handlers. The documentation for Event.preventDefault() doesn't mention what happens if it's called in a filter. Event.preventDefault() is only useful if a primary handler or filter wants to skip the default without consuming the event. This sounds reasonable but I can?t come up with a specific use case. Could you provide an example? It?s unfortunate that the only way for a handler to send information to a dispatcher is to attach it as state on the event (and it?s unfortunate that there's no good way to keep that state from bleeding over to another dispatcher). If we?re going through the trouble we should consider generalizing this and opening it up. For example, we could allow a handler or filter to attach an arbitrary object to the event for the dispatcher to retrieve. It?s worth thinking about (if only for a moment). On the flip side preventDefault() is well-defined and based on a web standard so it makes sense to add this bit even it?s only used by Control or Node. Martin > On Jan 5, 2026, at 8:46?AM, Andy Goryachev wrote: > > Michael: > > Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ? > > Thanks, > -andy > > > > From: openjfx-dev on behalf of Michael Strau? > Date: Thursday, December 25, 2025 at 02:49 > To: openjfx-dev > Subject: Re: Default event handlers > > I've run into some problems while trying to make event handlers on > skins only act when the event isn't consumed by user code. Consider a > button that is nested in some hierarchy: > > scene > --> root > ----> button > > When the button receives a MOUSE_RELEASED event, it consumes the event > and fires off an ACTION event. Doing that in a default handler is > fine, but as as consequence, the MOUSE_RELEASED event won't be > immediately consumed. Instead, it bubbles up the entire hierarchy > before it is finally handled and consumed by the button in its default > handler after the dispatch chain has completed. This is clearly not > what we want, as it can potentially cause ancestors to act on the > event, too. (By the way, this also rules out an event system where > events are dispatched in prioritized capture/bubble phases.) > > I think what we need is quite a bit simpler. Default event handlers > are still the way to go, but they shouldn't act across the entire > dispatch chain. Instead, they should only act locally on a single > event target: when a target receives an event, it first invokes its > regular handlers. Then, if the event is still eligible for default > handling, the default handlers are invoked. Skins and behaviors should > always use default handlers, never regular handlers. > > In the example, the button would consume the MOUSE_RELEASED event in > its default handler, which will prevent it from bubbling up the > hierarchy. If user code adds an event handler to the button, the user > handler will always be invoked first and gets to decide whether to > consume the event (Event.consume()), prevent the default handler from > running (Event.preventDefault()), or let it continue to flow. > > Using this simplified model, I've been able to switch over InputMap > and ListenerHelper (and therefore almost all controls) to use default > handling, and it seems to work pretty well. > > Here is a PR with the implementation: https://github.com/openjdk/jfx/pull/2022 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jan 9 22:47:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 22:47:03 GMT Subject: RFR: 8374909: CodeArea: Exception in IME Message-ID: Adds several tests and fixes export range bugs in the `StyledTextModel`. ------------- Commit messages: - lf - whitespace - fix - tests Changes: https://git.openjdk.org/jfx/pull/2029/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374909 Stats: 242 lines in 7 files changed: 198 ins; 30 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/2029.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2029/head:pull/2029 PR: https://git.openjdk.org/jfx/pull/2029 From angorya at openjdk.org Fri Jan 9 23:19:26 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 9 Jan 2026 23:19:26 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v2] In-Reply-To: References: Message-ID: > Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) > > Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: limit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2029/files - new: https://git.openjdk.org/jfx/pull/2029/files/46ef7baa..f7405a19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2029&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2029&range=00-01 Stats: 84 lines in 2 files changed: 81 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2029.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2029/head:pull/2029 PR: https://git.openjdk.org/jfx/pull/2029 From duke at openjdk.org Sun Jan 11 17:07:12 2026 From: duke at openjdk.org (Huang Xiao) Date: Sun, 11 Jan 2026 17:07:12 GMT Subject: RFR: 8185887: Fix VirtualFlow performance regression in ListView scrolling Message-ID: The commit 1b12c8a490 introduced two performance issues in VirtualFlow: 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 1000+ items). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. ------------- Commit messages: - 8185887: Fix VirtualFlow performance regression in ListView scrolling Changes: https://git.openjdk.org/jfx/pull/2030/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8185887 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2030.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2030/head:pull/2030 PR: https://git.openjdk.org/jfx/pull/2030 From mstrauss at openjdk.org Sun Jan 11 18:56:26 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 11 Jan 2026 18:56:26 GMT Subject: RFR: 8364149: Conditional stylesheet imports Message-ID: The [`@import`](https://www.w3.org/TR/css-cascade-5/#at-import) rule is extended to support conditional stylesheet imports: @import [ | ] ? ; Conceptually, a conditional import takes all rules of the referenced stylesheet, literally includes them at the location of the `@import` rule, and surrounds them with a `@media` rule with the specified ``. The implementation of this feature extends media queries with a context-free evaluation function: interface MediaQuery { TriState evaluate(); // returns TRUE / FALSE / UNKNOWN } This mode of evaluation uses Kleene's strong trivalent logic to determine whether the media query will always match (it's a tautology), will never match (it's a contradiction), or whether it depends on the context or we simply don't know. Using this mechanism, a conditional stylesheet import that can never match will be skipped at runtime. Similarly, a conditional stylesheet import that will always match doesn't need the `` at all; its rules will be pasted verbatim into the main stylesheet. Note that this mechanism is _not_ meant to be a full-blown theorem solver. It won't detect that, for example, the following import conditions will always match: @import url("stylesheet.css") (width > 1000) or (width <= 1000); Its purpose is an optimization for "obvious" cases. For example, at the moment the built-in themes use hard-coded conditions to include user-agent stylesheets at runtime: // in PlatformImpl.java: if (isSupported(ConditionalFeature.INPUT_TOUCH)) { uaStylesheets.add("com/sun/javafx/scene/control/skin/modena/touch.css"); } In the future, we might have a way to test for `ConditionalFeature` flags that achieves the same thing, but with a public API available to all theme authors: @import url("com/sun/javafx/scene/control/skin/modena/touch.css") (-fx-supports-conditional-feature: input-touch); ------------- Commit messages: - Conditional stylesheet imports Changes: https://git.openjdk.org/jfx/pull/2031/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2031&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364149 Stats: 934 lines in 21 files changed: 821 ins; 45 del; 68 mod Patch: https://git.openjdk.org/jfx/pull/2031.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2031/head:pull/2031 PR: https://git.openjdk.org/jfx/pull/2031 From duke at openjdk.org Mon Jan 12 03:37:27 2026 From: duke at openjdk.org (Huang Xiao) Date: Mon, 12 Jan 2026 03:37:27 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 17:01:32 GMT, Huang Xiao wrote: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 1000+ items). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins > maven-compiler-plugin > 3.11.0 > > ${java.version} > ${java.version} > > > > > > org.openjfx > javafx-maven-plugin > ${... I discovered that version 25 has performance issues locally, and it works fine when rolling back to version 24. I don't have sufficient permissions and also don't have a place to report this issue. The current workaround is to roll back to version 24. However, I'm not sure if this is a destructive change. @Maran23 Hello, I noticed you've made contributions to this area before. Could you help me review this issue? A relatively complete code example has been provided above. If you need a directly usable attachment, I can provide it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3736764476 PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3736766299 From arapte at openjdk.org Mon Jan 12 06:59:05 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 12 Jan 2026 06:59:05 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:32:56 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 2026 Overall looks good to me, with one query and a comment in the discussion that @Maran23 had started about traversal in getAncestorOfClass(). modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/RichUtils.java line 767: > 765: } > 766: } > 767: return null; It seems this if condition would never be true in current situation, and very likely be never true in future in context of RTA. A VFlow cannot be Window. Can this code be removed ? keeping only the required else block. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1975#pullrequestreview-3649236786 PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2680933790 From arapte at openjdk.org Mon Jan 12 06:59:06 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 12 Jan 2026 06:59:06 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTLASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com> References: <5VyBDD2XQvsuhNu3DRF6XXSwSzTe3BaN_13HdThVwxE=.86a1a532-e60c-4abc-a8f9-953ee2d1546e@github.com> <15B47nEG5NEyJ3_nw6BLCYOvM8HhUi2QtYzD4WQjpVI=.21e08564-174a-491b-8071-d7f12556a5cf@github.com> <82HYP1uLEGi0kmqTxpcNLzGMcYXvFu1TOTL ASSWR6TI=.cf084c42-17ba-4cc5-9ece-11f74f05328d@github.com> Message-ID: <0u5yXnfX3XUG6XToTrIMver8Z9Vj2k60yUjRZ66Tk1c=.872cb4d3-42bb-4424-8f6a-f79cae8ed849@github.com> On Sat, 22 Nov 2025 16:42:49 GMT, Marius Hanl wrote: >> The documentation on `Node.managed` property states >> >> Defines whether or not this node's layout will be managed by its parent. >> >> >> The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**. >> >> The `VFlow` is the entity that does the layout, for a reason. It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1). >> >> Notes >> >> 1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR) > > Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again. > > To reiterate, what is the problem? > - We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns > - This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else? > - Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy > - Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set? > > Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945 > So I would like to know, if maybe there was a bug even? I also had a similar concern as @Maran23. But, after looking it more closely, It seems to be acceptable and needed solution for this scenario. Few aspects: 1. Alternative approaches would be to save a reference to parent VFlow in each TextCell or a listener property. Which could be huge number, as there would be **n** TextCells (non-node embedding) under a VFlow. 2. The parent traversal is always fixed, i.e. only one time, as VFlow is immediate parent of a TextCell. 3. The re-layouts of VFlow are be limited, once a pulse. and at-least one is required. 3.1 even if multiple Node embedding TextCells get modified in a pulse. 3.2 even with multiple layout of a TextCell in a pulse Overall this seems safe, with fixed negligible impact on performance, as traversal happens only for the modified TextCell. So, it would be one traversal for modified node(very likely one node in a frame/pulse). and alternative approaches would increase memory consumption depending on number of TextCells. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2681053781 From jvos at openjdk.org Mon Jan 12 07:48:49 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 12 Jan 2026 07:48:49 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 03:33:41 GMT, Huang Xiao wrote: > @Maran23 Hello, I noticed you've made contributions to this area before. Could you help me review this issue? > > A relatively complete code example has been provided above. If you need a directly usable attachment, I can provide it. Hi @youngledo , thanks for reporting this. To follow the normal procedure, can you please file a bug in https://bugs.java.com/bugreport/ ? When doing that, there is (after manual triage) machinery going on behind the scenes that facilitates the whole flow between bug report, discussions, PR, release docs etc. I believe there is a fair chance indeed that the code you mention can lead to regression in a number of situations. Your code sample would be helpful, but is best provided after you report the bug. I notice there are @FXML refs but I don't see an FXML file, so I suggest you upload a zip file (once the issue is in JBS). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3737252472 From duke at openjdk.org Mon Jan 12 10:01:53 2026 From: duke at openjdk.org (Huang Xiao) Date: Mon, 12 Jan 2026 10:01:53 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 07:45:44 GMT, Johan Vos wrote: > > @Maran23 Hello, I noticed you've made contributions to this area before. Could you help me review this issue? > > A relatively complete code example has been provided above. If you need a directly usable attachment, I can provide it. > > Hi @youngledo , thanks for reporting this. To follow the normal procedure, can you please file a bug in https://bugs.java.com/bugreport/ ? When doing that, there is (after manual triage) machinery going on behind the scenes that facilitates the whole flow between bug report, discussions, PR, release docs etc. > > I believe there is a fair chance indeed that the code you mention can lead to regression in a number of situations. Your code sample would be helpful, but is best provided after you report the bug. I notice there are @FXML refs but I don't see an FXML file, so I suggest you upload a zip file (once the issue is in JBS). @johanvos Sorry, I forgot to mention that since I'm just a regular user, I couldn't figure out how to become a member. Could you help me submit the issue, or what should I do instead? The sample project has been uploaded: [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) ------------- PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3737722912 From crschnick at xpipe.io Mon Jan 12 13:45:04 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Mon, 12 Jan 2026 14:45:04 +0100 Subject: Bug report notification links don't work Message-ID: <3bf0eaa8-764e-4129-a0ef-a97ae0476f50@xpipe.io> I reported JDK-8375016 via the Java bug submit form as I don't have a JBS account yet. I got an automated confirmation from Bug-Report-Daemon_WW at ORACLE.COM that points to http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8375016, which I can't open. From duke at openjdk.org Mon Jan 12 14:19:42 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 14:19:42 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase Message-ID: This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. ------------- Commit messages: - Fixes - More fixes - Handle exceptions better Changes: https://git.openjdk.org/jfx/pull/2032/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375016 Stats: 371 lines in 9 files changed: 8 ins; 215 del; 148 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From angorya at openjdk.org Mon Jan 12 15:38:14 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 15:38:14 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v7] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 05:42:13 GMT, Ambarish Rapte wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> 2026 > > modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/RichUtils.java line 767: > >> 765: } >> 766: } >> 767: return null; > > It seems this if condition would never be true in current situation, and very likely be never true in future in context of RTA. A VFlow cannot be Window. > Can this code be removed ? keeping only the required else block. You are right. This implementation was taken from another project I have that ensures that the right parent is returned, but in this particular case the `Window`- and `Menu`- specific code paths can be removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2682803068 From kevin.rushforth at oracle.com Mon Jan 12 15:47:12 2026 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Jan 2026 07:47:12 -0800 Subject: Bug report notification links don't work In-Reply-To: <3bf0eaa8-764e-4129-a0ef-a97ae0476f50@xpipe.io> References: <3bf0eaa8-764e-4129-a0ef-a97ae0476f50@xpipe.io> Message-ID: <32b79f54-5a62-49c6-8d33-1671eda2de71@oracle.com> I'll report the problem to the team that handles the bugs.java.com site. The direct URL to the bug (which you will see in the PR you created) is: https://bugs.openjdk.org/browse/JDK-8375016 and that link works. -- Kevin On 1/12/2026 5:45 AM, Christopher Schnick wrote: > I reported JDK-8375016 via the Java bug submit form as I don't have a > JBS account yet. I got an automated confirmation from > Bug-Report-Daemon_WW at ORACLE.COM that points to > http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8375016, which I > can't open. > From mstrauss at openjdk.org Mon Jan 12 16:24:42 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 12 Jan 2026 16:24:42 GMT Subject: RFR: 8369836: Update HeaderBar API [v18] 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: constant name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1936/files - new: https://git.openjdk.org/jfx/pull/1936/files/0707bd6a..8f2a7424 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1936&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 angorya at openjdk.org Mon Jan 12 16:24:42 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 16:24:42 GMT Subject: RFR: 8369836: Update HeaderBar API [v18] In-Reply-To: References: Message-ID: <8MJ9JMNLzZvdxaLt2tFCL8WJRHpSWs0mhllkAyYLSrg=.c224240e-cfe3-48e0-9ce3-15e67994f133@github.com> On Mon, 12 Jan 2026 16:20:26 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > constant name Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3651623021 From mhanl at openjdk.org Mon Jan 12 16:26:45 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 12 Jan 2026 16:26:45 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: <2jUqLY3Yl76qEraaKTlRHn6SluqfrW2UW7KCa0hHe4U=.fd071649-2494-4ae3-815f-f89bb9624647@github.com> On Mon, 12 Jan 2026 09:56:41 GMT, Huang Xiao wrote: > I forgot to mention that since I'm just a regular user, I couldn't figure out how to become a member You are an `Author`, so you should be able to login to https://bugs.openjdk.org/issues/?filter=39543. See also the message from `@bridgekeeper` > Welcome back youngledo Without checking your example, simply removing both lines of code is certainly not the right fix. This was implemented to fix problems, so I'm pretty sure this will lead to regressions. Also note that you should check if applying https://github.com/openjdk/jfx/pull/1945 fixes your problem, as this is an issue that could lead to many unnecessary relayouts right now. Note that I believe that the performance of the `VirtualFlow` can be improved a lot, but I'm not sure this is the right approach / the right place. Example: the `removeAll` should not be triggered that often and the pile should not be that big. If it is, we may need to check out why this is first. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3739399553 From angorya at openjdk.org Mon Jan 12 16:28:53 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 16:28:53 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: References: Message-ID: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> > Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. > > > ### NOTES > > - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) > - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest > > Screenshot 2025-11-17 at 13 43 12 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - review comments - Merge branch 'master' into 8371067.request.layout - 2026 - Merge branch 'master' into 8371067.request.layout - Merge branch 'master' into 8371067.request.layout - Merge branch 'master' into 8371067.request.layout - updated test - Merge branch 'master' into 8371067.request.layout - add text segment - Merge branch 'master' into 8371067.request.layout - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 ------------- Changes: https://git.openjdk.org/jfx/pull/1975/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1975&range=07 Stats: 83 lines in 4 files changed: 74 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1975.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1975/head:pull/1975 PR: https://git.openjdk.org/jfx/pull/1975 From mstrauss at openjdk.org Mon Jan 12 17:03:30 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 12 Jan 2026 17:03:30 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:11:48 GMT, Christopher Schnick wrote: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 7478: > 7476: return val; > 7477: } else { > 7478: Logging.getLogger().fine("Element not found in map, returning default value instead."); Why did you add this check? The old implementation doesn't check whether the mapping exists, it simply returns the result of `Map.get()`. On the other hand, `NullPointerException` is thrown by `Map.get()` if the key is null, and the map doesn't permit null keys. The old implementation would return null here end emit a warning, this implementation returns by throwing the exception. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683060660 From duke at openjdk.org Mon Jan 12 17:23:49 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 17:23:49 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 16:41:41 GMT, Michael Strau? wrote: >> This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. >> >> The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. > > modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 7478: > >> 7476: return val; >> 7477: } else { >> 7478: Logging.getLogger().fine("Element not found in map, returning default value instead."); > > Why did you add this check? The old implementation doesn't check whether the mapping exists, it simply returns the result of `Map.get()`. > > On the other hand, `NullPointerException` is thrown by `Map.get()` if the key is null, and the map doesn't permit null keys. The old implementation would return null here end emit a warning, this implementation returns by throwing the exception. Ok that is true, let me rework this PR ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683195003 From duke at openjdk.org Mon Jan 12 17:38:28 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 17:38:28 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: <1Oh6Lp5PAtbNLaQ7AYJgB3OL7dldyb9XaKYntxMDUB4=.e5b13473-6dbe-4178-9bab-ab8d303fb26b@github.com> On Mon, 12 Jan 2026 14:11:48 GMT, Christopher Schnick wrote: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. If I convert this to a draft, does that break anything? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2032#issuecomment-3739696690 From angorya at openjdk.org Mon Jan 12 17:41:35 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 17:41:35 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:11:48 GMT, Christopher Schnick wrote: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 199: > 197: return numberVal.doubleValue(); > 198: } else if (val != null) { > 199: Logging.getLogger().warning("Value of select-binding has wrong type, returning default value."); minor: I would re-phrase it as something like "Expecting a Number value" (here and elsewhere) modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 5187: > 5185: } else { > 5186: Integer result = slowMap.get(id); > 5187: if (result == null) { I don't think this is an equivalent change ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683187492 PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683199783 From angorya at openjdk.org Mon Jan 12 17:41:37 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 17:41:37 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:21:39 GMT, Christopher Schnick wrote: >> modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 7478: >> >>> 7476: return val; >>> 7477: } else { >>> 7478: Logging.getLogger().fine("Element not found in map, returning default value instead."); >> >> Why did you add this check? The old implementation doesn't check whether the mapping exists, it simply returns the result of `Map.get()`. >> >> On the other hand, `NullPointerException` is thrown by `Map.get()` if the key is null, and the map doesn't permit null keys. The old implementation would return null here end emit a warning, this implementation returns by throwing the exception. > > Ok that is true, let me rework this PR I agree, the change is not equivalent... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683195725 From angorya at openjdk.org Mon Jan 12 17:48:15 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 17:48:15 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: <1Oh6Lp5PAtbNLaQ7AYJgB3OL7dldyb9XaKYntxMDUB4=.e5b13473-6dbe-4178-9bab-ab8d303fb26b@github.com> References: <1Oh6Lp5PAtbNLaQ7AYJgB3OL7dldyb9XaKYntxMDUB4=.e5b13473-6dbe-4178-9bab-ab8d303fb26b@github.com> Message-ID: On Mon, 12 Jan 2026 17:34:31 GMT, Christopher Schnick wrote: > If I convert this to a draft, does that break anything? Converting back to draft means a serious rework is needed, since we don't want to spend time reviewing a PR that will be changed in a major way. If you are simply addressing localized review comments, it's ok to have it Open, I think. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2032#issuecomment-3739733970 From duke at openjdk.org Mon Jan 12 17:48:17 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 17:48:17 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 14:11:48 GMT, Christopher Schnick wrote: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Well that depends on what serious means here. I would consider it serious, so I am moving it to a draft to figure out how to retain the exact behaviour of the old implementation ------------- PR Comment: https://git.openjdk.org/jfx/pull/2032#issuecomment-3739738528 From duke at openjdk.org Mon Jan 12 19:37:57 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 19:37:57 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v2] In-Reply-To: References: Message-ID: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: - Fix visibility - Fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2032/files - new: https://git.openjdk.org/jfx/pull/2032/files/855ed2f5..9465dc83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=00-01 Stats: 49 lines in 1 file changed: 10 ins; 10 del; 29 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From duke at openjdk.org Mon Jan 12 19:37:59 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 19:37:59 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:21:53 GMT, Andy Goryachev wrote: >> Ok that is true, let me rework this PR > > I agree, the change is not equivalent... Ok, this should be fixed. I centralized the map exception handling in a separate method to avoid duplication. It now catches all Map.get() exceptions in case someone is using some weird custom map implementation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683620998 From duke at openjdk.org Mon Jan 12 19:38:00 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 19:38:00 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:22:59 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix visibility >> - Fixes > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 5187: > >> 5185: } else { >> 5186: Integer result = slowMap.get(id); >> 5187: if (result == null) { > > I don't think this is an equivalent change I don't see the issue with this one though. The NPE can only occur if the null result is unboxed, right? The get function itself should not throw an exception ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683319759 From angorya at openjdk.org Mon Jan 12 19:38:01 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 19:38:01 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:00:47 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 5187: >> >>> 5185: } else { >>> 5186: Integer result = slowMap.get(id); >>> 5187: if (result == null) { >> >> I don't think this is an equivalent change > > I don't see the issue with this one though. The NPE can only occur if the null result is unboxed, right? The get function itself should not throw an exception you are right, `slowMap` is always initialized and a NPE can come only from unboxing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2683339796 From kcr at openjdk.org Mon Jan 12 21:43:06 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 12 Jan 2026 21:43:06 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 Message-ID: Bump the version number of JavaFX to 27. I will integrate this to master as part of forking the `jfx26` stabilization branch, which is scheduled for Thursday, January 15, 2026 at 16:00 UTC. ------------- Commit messages: - 8375067: Change JavaFX release version to 27 Changes: https://git.openjdk.org/jfx/pull/2033/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375067 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2033.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2033/head:pull/2033 PR: https://git.openjdk.org/jfx/pull/2033 From angorya at openjdk.org Mon Jan 12 21:53:59 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 21:53:59 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:35:09 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 27. I will integrate this to master as part of forking the `jfx26` stabilization branch, which is scheduled for Thursday, January 15, 2026 at 16:00 UTC. Marked as reviewed by angorya (Reviewer). modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java line 41: > 39: > 40: // Increment this feature-release counter for every major release. > 41: private static final String FEATURE = "27"; minor suggestion: maybe add a comment listing all the files that need to be updated? not sure where though. ------------- PR Review: https://git.openjdk.org/jfx/pull/2033#pullrequestreview-3652876920 PR Review Comment: https://git.openjdk.org/jfx/pull/2033#discussion_r2684025205 From duke at openjdk.org Mon Jan 12 22:13:57 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 22:13:57 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none Message-ID: A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent ------------- Commit messages: - Remove excessive comment - Fix possible NPE Changes: https://git.openjdk.org/jfx/pull/2034/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375070 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2034.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2034/head:pull/2034 PR: https://git.openjdk.org/jfx/pull/2034 From angorya at openjdk.org Mon Jan 12 22:44:22 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 22:44:22 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick wrote: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point I'll try testing it, but it would be nice to learn more about the actual failure mode - which mouse model, which driver, etc. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3740834261 From duke at openjdk.org Mon Jan 12 22:44:23 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 22:44:23 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick wrote: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point Yeah I would like to know as well, but that's the thing with user reports. Often they don't follow up, but an initial report is still better than nothing ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3740841837 From angorya at openjdk.org Mon Jan 12 22:56:07 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 22:56:07 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick wrote: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point The danger in such poorly understood cases is the risk of regression. This code was written in 2012 (or probably even earlier) and might have worked fine since then (or might not, it's hard to say). In order to analyze the change, we do need a reproducible code example or instructions how to reproduce, per https://bugreport.java.com/bugreport/ [FAQ](https://bugreport.java.com/bugdatabase/faq) [guide to submitting a bug report](https://docs.oracle.com/en/java/javase/21/troubleshoot/submit-bug-report.html#GUID-0074B0D4-7660-4542-9DD4-8E7C33637474) ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3740874118 From angorya at openjdk.org Mon Jan 12 23:01:14 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 23:01:14 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick wrote: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point I've got the Logitech MX Anywhere 2S mouse with a bunch of extra buttons and no specially installed driver, and I cannot reproduce the exception with the latest master branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3740886500 From duke at openjdk.org Mon Jan 12 23:18:03 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 23:18:03 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:07:16 GMT, Christopher Schnick wrote: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point Yes, I understand. The only reason I submitted this was because I have seen it multiple times now and the fix does not seem to have any adverse effects on other stuff. It should be reproducible in headless mode when sending an event manually. I will try to create a reproducer for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3740928808 From duke at openjdk.org Mon Jan 12 23:40:37 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 23:40:37 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v2] In-Reply-To: References: Message-ID: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Retain original logic better ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2034/files - new: https://git.openjdk.org/jfx/pull/2034/files/ea068f4c..f6f88a54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2034.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2034/head:pull/2034 PR: https://git.openjdk.org/jfx/pull/2034 From andy.goryachev at oracle.com Mon Jan 12 23:43:35 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 12 Jan 2026 23:43:35 +0000 Subject: [External] : Re: Default event handlers In-Reply-To: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> Message-ID: I kind of share Martin's sentiment. In my opinion, there are two general problems with the FX event dispatching: 1. general lack of predictability in the order of event handling which becomes a problem when skin gets replaced in Control 2. Event.isConsumed() debacle and the possibility of creating a malformed dispatcher by the application, something that should not be possible For #1, Michael tried adding event handling priorities, and I suggested to use the InputMap specifically for Controls (Andy), both of which did not get traction for various reasons. In Swing, this issue can easily be solved via removing and re-registering listeners at the right order via public API, if I remember correctly. We can't use that in FX because the listeners are not accessible to the application code. To me, either solution is fine (of course, I favor the InputMap one because it limits the number of effective priorities to a minimum required for the skins to function, since the application code can always add a listener at higher priority, and because the application code cannot use priorities given to skins, while at the same time allowing for custom skins). The main reason I dislike the idea of "default event handlers" is that it's a public API that can be misused by the application code and break the skins (if I read it correctly). The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? What do you think? -andy From: Martin Fox Date: Friday, January 9, 2026 at 10:36 To: Michael Strau? Cc: OpenJFX , Andy Goryachev Subject: [External] : Re: Default event handlers Default handlers might make sense for Control (it?s reasonable to assume that a behavior or skin may install handlers) but the rest of the system avoids using handlers and instead relies on custom dispatchers. It seems wrong to add calls for registering default handlers on Scene and Window when they make a point of not using handlers to begin with. Could we restrict this to Control? Or at the very least Node? If this was restricted to Control would we still make the call for registering a default handler public? For existing controls outside developers should only register primary handlers. The documentation for Event.preventDefault() doesn't mention what happens if it's called in a filter. Event.preventDefault() is only useful if a primary handler or filter wants to skip the default without consuming the event. This sounds reasonable but I can?t come up with a specific use case. Could you provide an example? It?s unfortunate that the only way for a handler to send information to a dispatcher is to attach it as state on the event (and it?s unfortunate that there's no good way to keep that state from bleeding over to another dispatcher). If we?re going through the trouble we should consider generalizing this and opening it up. For example, we could allow a handler or filter to attach an arbitrary object to the event for the dispatcher to retrieve. It?s worth thinking about (if only for a moment). On the flip side preventDefault() is well-defined and based on a web standard so it makes sense to add this bit even it?s only used by Control or Node. Martin On Jan 5, 2026, at 8:46?AM, Andy Goryachev wrote: Michael: Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ? Thanks, -andy From: openjfx-dev on behalf of Michael Strau? Date: Thursday, December 25, 2025 at 02:49 To: openjfx-dev Subject: Re: Default event handlers I've run into some problems while trying to make event handlers on skins only act when the event isn't consumed by user code. Consider a button that is nested in some hierarchy: scene --> root ----> button When the button receives a MOUSE_RELEASED event, it consumes the event and fires off an ACTION event. Doing that in a default handler is fine, but as as consequence, the MOUSE_RELEASED event won't be immediately consumed. Instead, it bubbles up the entire hierarchy before it is finally handled and consumed by the button in its default handler after the dispatch chain has completed. This is clearly not what we want, as it can potentially cause ancestors to act on the event, too. (By the way, this also rules out an event system where events are dispatched in prioritized capture/bubble phases.) I think what we need is quite a bit simpler. Default event handlers are still the way to go, but they shouldn't act across the entire dispatch chain. Instead, they should only act locally on a single event target: when a target receives an event, it first invokes its regular handlers. Then, if the event is still eligible for default handling, the default handlers are invoked. Skins and behaviors should always use default handlers, never regular handlers. In the example, the button would consume the MOUSE_RELEASED event in its default handler, which will prevent it from bubbling up the hierarchy. If user code adds an event handler to the button, the user handler will always be invoked first and gets to decide whether to consume the event (Event.consume()), prevent the default handler from running (Event.preventDefault()), or let it continue to flow. Using this simplified model, I've been able to switch over InputMap and ListenerHelper (and therefore almost all controls) to use default handling, and it seems to work pretty well. Here is a PR with the implementation: https://github.com/openjdk/jfx/pull/2022 -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jan 12 23:54:39 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 23:54:39 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Preserve original logic even more ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2034/files - new: https://git.openjdk.org/jfx/pull/2034/files/f6f88a54..836b88eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/2034.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2034/head:pull/2034 PR: https://git.openjdk.org/jfx/pull/2034 From angorya at openjdk.org Mon Jan 12 23:54:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 12 Jan 2026 23:54:39 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:51:14 GMT, Christopher Schnick wrote: >> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Preserve original logic even more modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: > 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } > 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } > 3721: if (cc != null) { this looks far safer, though it's still unclear why this might happen. perhaps it's a problem with the test code and not the product? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2684280627 From duke at openjdk.org Mon Jan 12 23:54:40 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 12 Jan 2026 23:54:40 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:47:56 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Preserve original logic even more > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: > >> 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } >> 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } >> 3721: if (cc != null) { > > this looks far safer, though it's still unclear why this might happen. perhaps it's a problem with the test code and not the product? If I get this correctly, if an event with an unknown raw mouse button index is sent, then this will map it MouseButton.NONE and cc will be null: https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java#L234 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2684286855 From duke at openjdk.org Tue Jan 13 00:01:01 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 00:01:01 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:51:14 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: >> >>> 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } >>> 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } >>> 3721: if (cc != null) { >> >> this looks far safer, though it's still unclear why this might happen. perhaps it's a problem with the test code and not the product? > > If I get this correctly, if an event with an unknown raw mouse button index is sent, then this will map it MouseButton.NONE and cc will be null: https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java#L234 I saw a comment to another issue in https://github.com/openjdk/jfx/blob/fd30c94893156644c0d803b3e7fd8c9731d65fe6/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java#L302 but somehow I can't access it. So no idea what this was about ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2684295660 From kcr at openjdk.org Tue Jan 13 00:02:49 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 00:02:49 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 19:37:57 GMT, Christopher Schnick wrote: >> This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. >> >> The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Fix visibility > - Fixes This will need careful review, and probably additional tests, to ensure that there are no regressions or changes in behavior. We will need to run it through our headful test system as well, since headless sanity testing is not going to be sufficient here. This isn't something I want to do quickly, so this will need to wait until after the jfx26 fork and we have sufficient time to test it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2032#issuecomment-3741067839 From kcr at openjdk.org Tue Jan 13 00:18:31 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 00:18:31 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: References: Message-ID: <8NKzOyWyAOXTdj_PuvtTYSozKGCnDx6EXFULbWGtkyM=.23c2d540-a804-47f9-b18a-98efdc3dc7c7@github.com> On Mon, 12 Jan 2026 21:49:12 GMT, Andy Goryachev wrote: >> Bump the version number of JavaFX to 27. I will integrate this to master as part of forking the `jfx26` stabilization branch, which is scheduled for Thursday, January 15, 2026 at 16:00 UTC. > > modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java line 41: > >> 39: >> 40: // Increment this feature-release counter for every major release. >> 41: private static final String FEATURE = "27"; > > minor suggestion: maybe add a comment listing all the files that need to be updated? not sure where though. Already implemented. See [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2033#discussion_r2684337898 From duke at openjdk.org Tue Jan 13 01:33:59 2026 From: duke at openjdk.org (Huang Xiao) Date: Tue, 13 Jan 2026 01:33:59 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: <2jUqLY3Yl76qEraaKTlRHn6SluqfrW2UW7KCa0hHe4U=.fd071649-2494-4ae3-815f-f89bb9624647@github.com> References: <2jUqLY3Yl76qEraaKTlRHn6SluqfrW2UW7KCa0hHe4U=.fd071649-2494-4ae3-815f-f89bb9624647@github.com> Message-ID: On Mon, 12 Jan 2026 16:23:11 GMT, Marius Hanl wrote: >>> > @Maran23 Hello, I noticed you've made contributions to this area before. Could you help me review this issue? >>> > A relatively complete code example has been provided above. If you need a directly usable attachment, I can provide it. >>> >>> Hi @youngledo , thanks for reporting this. To follow the normal procedure, can you please file a bug in https://bugs.java.com/bugreport/ ? When doing that, there is (after manual triage) machinery going on behind the scenes that facilitates the whole flow between bug report, discussions, PR, release docs etc. >>> >>> I believe there is a fair chance indeed that the code you mention can lead to regression in a number of situations. Your code sample would be helpful, but is best provided after you report the bug. I notice there are @FXML refs but I don't see an FXML file, so I suggest you upload a zip file (once the issue is in JBS). >> >> >> @johanvos >> Sorry, I forgot to mention that since I'm just a regular user, I couldn't figure out how to become a member. Could you help me submit the issue, or what should I do instead? >> >> The sample project has been uploaded: >> [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > >> I forgot to mention that since I'm just a regular user, I couldn't figure out how to become a member > > You are an `Author`, so you should be able to login to https://bugs.openjdk.org/issues/?filter=39543. > See also the message from `@bridgekeeper` >> Welcome back youngledo > > Without checking your example, simply removing both lines of code is certainly not the right fix. This was implemented to fix problems, so I'm pretty sure this will lead to regressions. > > Also note that you should check if applying https://github.com/openjdk/jfx/pull/1945 fixes your problem, as this is an issue that could lead to many unnecessary relayouts right now. > > Note that I believe that the performance of the `VirtualFlow` can be improved a lot, but I'm not sure this is the right approach / the right place. > Example: the `removeAll` should not be triggered that often and the pile should not be that big. If it is, we may need to check out why this is first. @Maran23 Thank you for your reply. I am not an author yet; I am still in the application process. Yes, you're right that deleting the code isn't appropriate, but I tried using the published version 24 locally and it worked fine. Moreover, the sample code provided above is very simple, and it shouldn't be this laggy even when generating only a few entries. I forgot to mention, my system environment is: - Apple M1 - macOS 26.2 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2030#issuecomment-3741362221 From arapte at openjdk.org Tue Jan 13 01:45:10 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 13 Jan 2026 01:45:10 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> References: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> Message-ID: On Mon, 12 Jan 2026 16:28:53 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge branch 'master' into 8371067.request.layout > - 2026 > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - updated test > - Merge branch 'master' into 8371067.request.layout > - add text segment > - Merge branch 'master' into 8371067.request.layout > - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 lgtm ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1975#pullrequestreview-3653428675 From jvos at openjdk.org Tue Jan 13 07:32:15 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 13 Jan 2026 07:32:15 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:35:09 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 27. I will integrate this to master as part of forking the `jfx26` stabilization branch, which is scheduled for Thursday, January 15, 2026 at 16:00 UTC. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2033#pullrequestreview-3654261523 From jvos at openjdk.org Tue Jan 13 08:02:03 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 13 Jan 2026 08:02:03 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. I had a deeper look. All code changes look fine, and I believe it is the right thing to do (including the support for flatpak) We have some technical debt when using GTK, and using deprecated constants like STOCK_OPEN add to this debt. On my Ubuntu 22.04, the icons are not even shown with the existing implementation, so there is no difference for me, as far as I see. @fthevenet what OS/GTK version is used for the screenshot that you pasted and that does have the icons? I'm pretty neutral on design in general, but it seems that removing the option to show an icon next to the label is aligning us more with industry standards. Since this is about an OS/Gnome component, I believe there is no problem if this results (on some systems) in a changed UI -- other apps will probably show similar evolution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3742633917 From fthevenet at openjdk.org Tue Jan 13 08:37:43 2026 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Tue, 13 Jan 2026 08:37:43 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 13 Jan 2026 07:58:03 GMT, Johan Vos wrote: >> Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. >> To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. >> >> Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. >> One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. >> >> GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. >> When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. > > I had a deeper look. All code changes look fine, and I believe it is the right thing to do (including the support for flatpak) > We have some technical debt when using GTK, and using deprecated constants like STOCK_OPEN add to this debt. On my Ubuntu 22.04, the icons are not even shown with the existing implementation, so there is no difference for me, as far as I see. > @fthevenet what OS/GTK version is used for the screenshot that you pasted and that does have the icons? > > I'm pretty neutral on design in general, but it seems that removing the option to show an icon next to the label is aligning us more with industry standards. Since this is about an OS/Gnome component, I believe there is no problem if this results (on some systems) in a changed UI -- other apps will probably show similar evolution. Thanks @johanvos I took those screenshot on Fedora 43 (with KDE 6.5.4). The version of the bundled GTK3 libs is 3.24.51. Another issue I've noticed with these icons is that if I run a light color theme on my env, the icons are still there but almost invisible, as they are drawn in white on a very light grey background: image If you click the button so its background color changes, you can see the icon it still there: image Maybe this is what's happening on your machine, @johanvos ? At any rate, for all the reasons you mentioned, I believe it's not really worth investigating this particular problem further and that simply getting rid of the icons is the best way forward. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3742838570 From arapte at openjdk.org Tue Jan 13 09:27:30 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 13 Jan 2026 09:27:30 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:54:39 GMT, Christopher Schnick wrote: >> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Preserve original logic even more modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: > 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } > 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } > 3721: if (cc != null) { Instead of a null check, I would recommend to validate the MouseEvent **e**. `counters` does not have an entry for `MouseButton.NONE`, instead of null check below check could fit better: `if (e.getButton() == MouseButton.NONE) return;` Looks like in this issue scenario this is true: `e.getButton() == MouseButton.NONE && e.getEventType() == MouseEvent.MOUSE_PRESSED`. It would be good to understand why this is happening? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2685595061 From duke at openjdk.org Tue Jan 13 10:38:07 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 10:38:07 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: <36AuvrH_qYqmxzVKvPiTgS04g4BQ3Ro_t4Hl88rvg9E=.e9c08b48-a7f6-496c-800d-f633f9252859@github.com> On Tue, 13 Jan 2026 09:25:20 GMT, Ambarish Rapte wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Preserve original logic even more > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: > >> 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } >> 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } >> 3721: if (cc != null) { > > Instead of a null check, I would recommend to validate the MouseEvent **e**. > `counters` does not have an entry for `MouseButton.NONE`, instead of null check below check could fit better: > `if (e.getButton() == MouseButton.NONE) return;` > > Looks like in this issue scenario this is true: `e.getButton() == MouseButton.NONE && e.getEventType() == MouseEvent.MOUSE_PRESSED`. It would be good to understand why this is happening? About why this is happening, I saw a reference to JDK-8110944 in the mouse button handling code for the NONE type but the issue is not found for me. Is the bug ID wrong or is that a restricted issue? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2685814358 From john.hendrikx at gmail.com Tue Jan 13 12:52:09 2026 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 13 Jan 2026 13:52:09 +0100 Subject: [External] : Re: Default event handlers In-Reply-To: References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> Message-ID: <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> On 13/01/2026 00:43, Andy Goryachev wrote: > > The reason I mentioned #2 is that it is somewhat relevant to the > discussion, as in "why do we need to write custom dispatchers at all?" > ?There should be only two methods, in my opinion, one that dispatches > an event that bubbles up (with filters and handlers), and one that > sends an event to a single target Node and nothing else. > ?Somehow, Swing got the Events right - it manages to dispatch > one (1) event in total, and the dispatching stops once the event is > consumed. ?The?FX decided it needed to reinvent the wheel and leave > multiple booby traps in the process. Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides.? EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to.??The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target.? This cloning then caused the "isConsumed" problem.? Perhaps we should just make the source field mutable as well, so the cloning isn't needed. The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) > > This isn't exactly rocket science, we should be able to figure > something out. ?Maybe there is another option that will satisfy everyone? I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself.? Skin/Behaviors in FX is like giving root access to every user on your system.? Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great.? However one malicious user can interfere with others or leave behind hooks that later come to bite you. Controls are HOSTS for Skins and Behaviors.? Skins and Behaviors are clients.? They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference.? Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors.? All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically.? This will greatly simplify skins, and remove a whole avenue of potential bugs. All work done through this API can be monitored by the Control. The control can: - Track what is installed (for later clean-up) - Reject installation of listeners/handlers it doesn't want to expose - Ensure that event handlers are installed at lowest precedence.? This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it.? Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code.? This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures.? For example: ??? > voidaddListener(Function supplier, Consumer subscriber) Allows installation of a listener by doing: ????api.addListener(Slider::minProperty, v -> { ... }); In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 13 15:26:25 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 15:26:25 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: <8NKzOyWyAOXTdj_PuvtTYSozKGCnDx6EXFULbWGtkyM=.23c2d540-a804-47f9-b18a-98efdc3dc7c7@github.com> References: <8NKzOyWyAOXTdj_PuvtTYSozKGCnDx6EXFULbWGtkyM=.23c2d540-a804-47f9-b18a-98efdc3dc7c7@github.com> Message-ID: <9ynrOqjFJhyoiiGOqflZZ4lgfFQGTnQ4y7GWRwuw70k=.07f89a70-6c71-4b2d-bd51-87362017c520@github.com> On Tue, 13 Jan 2026 00:16:11 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java line 41: >> >>> 39: >>> 40: // Increment this feature-release counter for every major release. >>> 41: private static final String FEATURE = "27"; >> >> minor suggestion: maybe add a comment listing all the files that need to be updated? not sure where though. > > Already implemented. See [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) yes, but assumes prior knowledge - it is not apparent in the github review. a reference to [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) would work though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2033#discussion_r2686896494 From duke at openjdk.org Tue Jan 13 15:26:26 2026 From: duke at openjdk.org (Jurgen) Date: Tue, 13 Jan 2026 15:26:26 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> References: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> Message-ID: On Mon, 12 Jan 2026 16:28:53 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge branch 'master' into 8371067.request.layout > - 2026 > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - updated test > - Merge branch 'master' into 8371067.request.layout > - add text segment > - Merge branch 'master' into 8371067.request.layout > - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 Marked as reviewed by Jugen at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx/pull/1975#pullrequestreview-3656397897 From angorya at openjdk.org Tue Jan 13 15:32:00 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 15:32:00 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: <9ynrOqjFJhyoiiGOqflZZ4lgfFQGTnQ4y7GWRwuw70k=.07f89a70-6c71-4b2d-bd51-87362017c520@github.com> References: <8NKzOyWyAOXTdj_PuvtTYSozKGCnDx6EXFULbWGtkyM=.23c2d540-a804-47f9-b18a-98efdc3dc7c7@github.com> <9ynrOqjFJhyoiiGOqflZZ4lgfFQGTnQ4y7GWRwuw70k=.07f89a70-6c71-4b2d-bd51-87362017c520@github.com> Message-ID: On Tue, 13 Jan 2026 15:23:02 GMT, Andy Goryachev wrote: >> Already implemented. See [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) > > yes, but assumes prior knowledge - it is not apparent in the github review. a reference to [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) would work though. I mean, it's just a suggestion, for the reviewers' sake. The changes are ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2033#discussion_r2686917937 From angorya at openjdk.org Tue Jan 13 16:27:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 16:27:03 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: <36AuvrH_qYqmxzVKvPiTgS04g4BQ3Ro_t4Hl88rvg9E=.e9c08b48-a7f6-496c-800d-f633f9252859@github.com> References: <36AuvrH_qYqmxzVKvPiTgS04g4BQ3Ro_t4Hl88rvg9E=.e9c08b48-a7f6-496c-800d-f633f9252859@github.com> Message-ID: On Tue, 13 Jan 2026 10:35:53 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3721: >> >>> 3719: if (! e.isBackButtonDown()) { counters.get(MouseButton.BACK).clear(); } >>> 3720: if (! e.isForwardButtonDown()) { counters.get(MouseButton.FORWARD).clear(); } >>> 3721: if (cc != null) { >> >> Instead of a null check, I would recommend to validate the MouseEvent **e**. >> `counters` does not have an entry for `MouseButton.NONE`. Instead of null check, below check could fit better: >> `if (e.getButton() == MouseButton.NONE) return;` >> >> Looks like in this issue scenario, this is turning out to be true: `e.getButton() == MouseButton.NONE && e.getEventType() == MouseEvent.MOUSE_PRESSED`. >> It would be good to understand why this is happening? > > About why this is happening, I saw a reference to JDK-8110944 in the mouse button handling code for the NONE type but the issue is not found for me. Is the bug ID wrong or is that a restricted issue? https://bugs.openjdk.org/browse/JDK-8110944 is public now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2687144727 From angorya at openjdk.org Tue Jan 13 16:34:49 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 16:34:49 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> References: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> Message-ID: On Mon, 12 Jan 2026 16:28:53 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge branch 'master' into 8371067.request.layout > - 2026 > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - updated test > - Merge branch 'master' into 8371067.request.layout > - add text segment > - Merge branch 'master' into 8371067.request.layout > - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 @lukostyra could you please take a look at this, so it gets into jfx26? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1975#issuecomment-3745278771 From kcr at openjdk.org Tue Jan 13 16:53:20 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 16:53:20 GMT Subject: RFR: 8375067: Change JavaFX release version to 27 In-Reply-To: References: <8NKzOyWyAOXTdj_PuvtTYSozKGCnDx6EXFULbWGtkyM=.23c2d540-a804-47f9-b18a-98efdc3dc7c7@github.com> <9ynrOqjFJhyoiiGOqflZZ4lgfFQGTnQ4y7GWRwuw70k=.07f89a70-6c71-4b2d-bd51-87362017c520@github.com> Message-ID: On Tue, 13 Jan 2026 15:28:20 GMT, Andy Goryachev wrote: >> yes, but assumes prior knowledge - it is not apparent in the github review. a reference to [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md) would work though. > > I mean, it's just a suggestion, for the reviewers' sake. The changes are ok. The JBS issues did have this information. > We need to update the release values in the following files: > > .jcheck/conf > build.properties > ... > modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java > > See https://github.com/openjdk/jfx/blob/master/UPDATING-VERSION.md for details. I suppose I could have copied that last line to this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2033#discussion_r2687247790 From angorya at openjdk.org Tue Jan 13 16:59:33 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 16:59:33 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v2] In-Reply-To: References: Message-ID: <1mPeUJZ-CFOQZ_Qn88nUYPlTBc9OwQrmsMi8rSc786g=.5d238db2-c82f-4806-a734-48f5870c0c7e@github.com> On Fri, 9 Jan 2026 23:19:26 GMT, Andy Goryachev wrote: >> Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) >> >> Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > limit @arapte could you please take a look at this so it makes it into jfx26? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2029#issuecomment-3745396458 From martinfox656 at gmail.com Tue Jan 13 16:59:26 2026 From: martinfox656 at gmail.com (Martin Fox) Date: Tue, 13 Jan 2026 08:59:26 -0800 Subject: [External] : Re: Default event handlers In-Reply-To: <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> Message-ID: <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> I didn?t intend to re-open all of these debates. I just wanted to point out that JavaFX in general uses dispatchers to process events so there?s no existing concept of default handlers outside of Control. If Control had implemented InputMap using a dispatcher we probably wouldn?t be having this conversation. I still believe this is a local problem for Control and it can craft its own solution. It doesn?t even have to involve handlers; look at how Scene and Menu handle accelerators. Whatever Control wants to do almost all of the tools are there. The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it. Rather than add a specialized bit like this PR does I thought it might be worth considering a more generalized solution (I can think of a few) but I?m actually fine with preventDefault() since it?s based on an existing standard. Martin > On Jan 13, 2026, at 4:52?AM, John Hendrikx wrote: > > > > On 13/01/2026 00:43, Andy Goryachev wrote: >> >> The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. > Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides. EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to. The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target. This cloning then caused the "isConsumed" problem. Perhaps we should just make the source field mutable as well, so the cloning isn't needed. > > The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) > >> >> This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? > I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself. Skin/Behaviors in FX is like giving root access to every user on your system. Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great. However one malicious user can interfere with others or leave behind hooks that later come to bite you. > > Controls are HOSTS for Skins and Behaviors. Skins and Behaviors are clients. They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: > > - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications > - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference. Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). > - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors > - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). > > That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. > > Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors. All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically. This will greatly simplify skins, and remove a whole avenue of potential bugs. > > All work done through this API can be monitored by the Control. The control can: > - Track what is installed (for later clean-up) > - Reject installation of listeners/handlers it doesn't want to expose > - Ensure that event handlers are installed at lowest precedence. This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. > > Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it. Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code. This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). > > The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures. For example: > > > void addListener(Function supplier, Consumer subscriber) > > Allows installation of a listener by doing: > > api.addListener(Slider::minProperty, v -> { ... }); > > In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). > > --John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jan 13 17:28:35 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 13 Jan 2026 17:28:35 +0000 Subject: [External] : Re: Default event handlers In-Reply-To: <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> Message-ID: Yes, I mostly agree with what you say John. I hope we can get to an agreement at some point regarding some sort of an InputMap that would simplify code for both skins, custom skins, and applications alike (maybe after jfx26 ships). Also, I know that the ship has sailed on EventDispatcher design, but the fact that Swing is perfectly fine without all this mess we have in FX is rather telling. Maybe, maybe, at some point in future, we could fix the isConsumed() bug, which is an API contract violation for the Event class, as well as implementation bug for the (multiple?) dispatcher classes, since they do happily dispatch already consumed events. Sorry for misdirecting the original thread (even though it is a related topic). If we can get back to the original proposal of the default handlers. I think Martin is right that the bulk of the problem is limited to the Controls - because of the skins that pop in and out of existence outside of application control like quantum particles, so perhaps the solution might be limited to Controls? But even if we resolve the event handling priority in controls via control-specific mechanism like InputMap, the issue might still exist in a different form. Consider the following scenario: Two different parts of the application (two libraries) add a handler to the same event. Without explicit event handler priorities, we'll see different invocation order depending on which library registers first at run time. Is this a real problem in the context of event dispatching, or we should say it's the responsibility of the application to ensure proper initialization sequence? -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, January 13, 2026 at 04:52 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Default event handlers On 13/01/2026 00:43, Andy Goryachev wrote: The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides. EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to. The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target. This cloning then caused the "isConsumed" problem. Perhaps we should just make the source field mutable as well, so the cloning isn't needed. The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself. Skin/Behaviors in FX is like giving root access to every user on your system. Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great. However one malicious user can interfere with others or leave behind hooks that later come to bite you. Controls are HOSTS for Skins and Behaviors. Skins and Behaviors are clients. They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference. Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors. All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically. This will greatly simplify skins, and remove a whole avenue of potential bugs. All work done through this API can be monitored by the Control. The control can: - Track what is installed (for later clean-up) - Reject installation of listeners/handlers it doesn't want to expose - Ensure that event handlers are installed at lowest precedence. This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it. Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code. This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures. For example: > void addListener(Function supplier, Consumer subscriber) Allows installation of a listener by doing: api.addListener(Slider::minProperty, v -> { ... }); In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jan 13 17:35:54 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 13 Jan 2026 17:35:54 +0000 Subject: [External] : Re: Default event handlers In-Reply-To: <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> Message-ID: I agree with Martin that this issue is mostly limited to Controls because of the skins. What was the main objection to the InputMap idea I proposed? I do want to ask Martin one thing though: what do you mean by "The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it." Can you give an example? Thanks! -andy From: openjfx-dev on behalf of Martin Fox Date: Tuesday, January 13, 2026 at 09:00 To: John Hendrikx Cc: OpenJFX Subject: Re: [External] : Re: Default event handlers I didn?t intend to re-open all of these debates. I just wanted to point out that JavaFX in general uses dispatchers to process events so there?s no existing concept of default handlers outside of Control. If Control had implemented InputMap using a dispatcher we probably wouldn?t be having this conversation. I still believe this is a local problem for Control and it can craft its own solution. It doesn?t even have to involve handlers; look at how Scene and Menu handle accelerators. Whatever Control wants to do almost all of the tools are there. The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it. Rather than add a specialized bit like this PR does I thought it might be worth considering a more generalized solution (I can think of a few) but I?m actually fine with preventDefault() since it?s based on an existing standard. Martin On Jan 13, 2026, at 4:52?AM, John Hendrikx wrote: On 13/01/2026 00:43, Andy Goryachev wrote: The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides. EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to. The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target. This cloning then caused the "isConsumed" problem. Perhaps we should just make the source field mutable as well, so the cloning isn't needed. The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself. Skin/Behaviors in FX is like giving root access to every user on your system. Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great. However one malicious user can interfere with others or leave behind hooks that later come to bite you. Controls are HOSTS for Skins and Behaviors. Skins and Behaviors are clients. They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference. Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors. All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically. This will greatly simplify skins, and remove a whole avenue of potential bugs. All work done through this API can be monitored by the Control. The control can: - Track what is installed (for later clean-up) - Reject installation of listeners/handlers it doesn't want to expose - Ensure that event handlers are installed at lowest precedence. This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it. Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code. This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures. For example: > void addListener(Function supplier, Consumer subscriber) Allows installation of a listener by doing: api.addListener(Slider::minProperty, v -> { ... }); In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jan 13 18:04:40 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 18:04:40 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v4] In-Reply-To: References: Message-ID: <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com> > A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2034/files - new: https://git.openjdk.org/jfx/pull/2034/files/836b88eb..8735a4e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2034&range=02-03 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2034.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2034/head:pull/2034 PR: https://git.openjdk.org/jfx/pull/2034 From duke at openjdk.org Tue Jan 13 18:12:28 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 18:12:28 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 23:54:39 GMT, Christopher Schnick wrote: >> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Preserve original logic even more I added a test case to reproduce this issue. I have two questions about the general workflow here: 1. If an issue is set to private, how does that happen / what does that mean? I was under the impression that all issues are public unless they are related to security or something. And the linked issue does not look like a security issue 2. How exactly is the requirement for a reproducer defined? Like if I observe that an issue is happening, but can't reproduce it manually, is a constructed test case good enough? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3745683675 From duke at openjdk.org Tue Jan 13 18:12:30 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 18:12:30 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: <36AuvrH_qYqmxzVKvPiTgS04g4BQ3Ro_t4Hl88rvg9E=.e9c08b48-a7f6-496c-800d-f633f9252859@github.com> Message-ID: On Tue, 13 Jan 2026 16:23:41 GMT, Andy Goryachev wrote: >> About why this is happening, I saw a reference to JDK-8110944 in the mouse button handling code for the NONE type but the issue is not found for me. Is the bug ID wrong or is that a restricted issue? > > https://bugs.openjdk.org/browse/JDK-8110944 is public now. I think the null check is in line with the rest of the method as it checks for cc != null later down for other types of events. I think instantly returning would not reset the click counters, which is also probably not the best solution. This null check is the most minimally invasive solution I can see. About why this happening, I guess that is a different thing to figure out. Looking at the related issue, it seems like a parent window can receive events from other windows under certain conditions. Maybe if you manage to click the split second a popup is shown / hidden, it can happen somehow ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2034#discussion_r2687518497 From duke at openjdk.org Tue Jan 13 20:10:25 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 13 Jan 2026 20:10:25 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v3] In-Reply-To: References: Message-ID: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary catch block ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2032/files - new: https://git.openjdk.org/jfx/pull/2032/files/9465dc83..70377bde Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From kcr at openjdk.org Tue Jan 13 20:47:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 20:47:01 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v3] In-Reply-To: References: Message-ID: <7PEmClX4_8duTvsvEN5yXtiCF29sbYzyIIt6DSC7xqY=.ddce2385-dfa2-45b7-bdc2-a4bba25ae3ce@github.com> On Tue, 13 Jan 2026 18:04:39 GMT, Christopher Schnick wrote: > 1. If an issue is set to private, how does that happen / what does that mean? I was under the impression that all issues are public unless they are related to security or something. And the linked issue does not look like a security issue An issue can be set to Confidential for a few different reasons. In the case of the bug you asked about -- [JDK-8110944](https://bugs.openjdk.org/browse/JDK-8110944) -- the component being fixed (glass) was not open source yet (note the resolution date: it was fixed in 2011). The bug didn't need to be Confidential, but no one noticed or asked about it until now. > 2. How exactly is the requirement for a reproducer defined? Like if I observe that an issue is happening, but can't reproduce it manually, is a constructed test case good enough? A constructed test case that fails before and passes after the fix is usually good enough as long as we understand _why_ the failure is occurring and _why_ the fix is the right one. So the questions being asked by @arapte are good questions to ask. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3746495722 From martinfox656 at gmail.com Tue Jan 13 21:35:37 2026 From: martinfox656 at gmail.com (Martin Fox) Date: Tue, 13 Jan 2026 13:35:37 -0800 Subject: [External] : Re: Default event handlers In-Reply-To: References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> Message-ID: <4DF01D8C-B0FE-4C12-93AA-1B972F4BB451@gmail.com> > On Jan 13, 2026, at 9:35?AM, Andy Goryachev wrote: > > I do want to ask Martin one thing though: what do you mean by "The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it." Can you give an example? This PR is the example. The Control class could implement primary and default handlers itself using existing mechanisms like rolling its own dispatchers. The only part it can?t do is have a primary handler communicate to the dispatcher that the default handlers should be skipped. There?s no existing mechanism for that; the only communication in that direction is the `consumed` bit. This PR had to add a global bit to all Events just for that. Again, that global bit might be the best solution. It?s based on an existing web event standard and is easy to define and to ignore if it?s not appropriate for a given source. Engineering a more general solution might be a waste of time. > Thanks! > > -andy > > > From: openjfx-dev on behalf of Martin Fox > Date: Tuesday, January 13, 2026 at 09:00 > To: John Hendrikx > Cc: OpenJFX > Subject: Re: [External] : Re: Default event handlers > > I didn?t intend to re-open all of these debates. I just wanted to point out that JavaFX in general uses dispatchers to process events so there?s no existing concept of default handlers outside of Control. If Control had implemented InputMap using a dispatcher we probably wouldn?t be having this conversation. > > I still believe this is a local problem for Control and it can craft its own solution. It doesn?t even have to involve handlers; look at how Scene and Menu handle accelerators. Whatever Control wants to do almost all of the tools are there. The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it. Rather than add a specialized bit like this PR does I thought it might be worth considering a more generalized solution (I can think of a few) but I?m actually fine with preventDefault() since it?s based on an existing standard. > > Martin > > On Jan 13, 2026, at 4:52?AM, John Hendrikx wrote: > > > > On 13/01/2026 00:43, Andy Goryachev wrote: > > The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. > Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides. EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to. The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target. This cloning then caused the "isConsumed" problem. Perhaps we should just make the source field mutable as well, so the cloning isn't needed. > > The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) > > > This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? > I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself. Skin/Behaviors in FX is like giving root access to every user on your system. Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great. However one malicious user can interfere with others or leave behind hooks that later come to bite you. > > Controls are HOSTS for Skins and Behaviors. Skins and Behaviors are clients. They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: > > - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications > - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference. Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). > - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors > - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). > > That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. > > Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors. All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically. This will greatly simplify skins, and remove a whole avenue of potential bugs. > > All work done through this API can be monitored by the Control. The control can: > - Track what is installed (for later clean-up) > - Reject installation of listeners/handlers it doesn't want to expose > - Ensure that event handlers are installed at lowest precedence. This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. > > Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it. Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code. This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). > > The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures. For example: > > > void addListener(Function supplier, Consumer subscriber) > > Allows installation of a listener by doing: > > api.addListener(Slider::minProperty, v -> { ... }); > > In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). > > --John > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Jan 13 21:44:44 2026 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 13 Jan 2026 22:44:44 +0100 Subject: [External] : Re: Default event handlers In-Reply-To: References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> Message-ID: <19689dff-2fda-4161-b094-cd5c91cd3b3b@gmail.com> Hi, The InputMap is a user of the event system.? It is basically a configurable event handler for a limited number of event types.? You could write one right now, expose it, and configure mappings, and in fact, to save on event handlers, this is exactly how many handlers already work.? Introducing it as an integral part of say Control immediately raises concerns; is InputMap going to be yet another event handler that users will have to fight when they install their own???At most I see this as part of a public Behavior API, where the Behavior can install (default) handlers, that then delegate to an accessible input map for that Behavior.? Swing doesn't have a Control/Behavior/Skin split, but FX does, and I think we should remain committed to that instead of making some Swing/QT/Compose Frankenstein hybrid here by copying features without thinking about the bigger picture and how they really fit into FX.? Furthermore, the current private InputMap implementation is, to put it midly, insanely inefficient, and so I find it incredibly hard to justify using even parts of that design. Everything in it is Observable, but nobody will be able to monitor it all for changes as that would entail installing hundreds of handlers for the average TextField input map.? What's also inefficient is that this input map gets recreated for each control, leading to several kilobytes of overhead for every TextField?in your application. There is just no reason to duplicate input maps like this as they're all going to be same 99.999% of the time.? If we want InputMaps, then I think we need to solve the Skin/Behavior split first -- this alone will be a huge win for FX, as reskinning then becomes trivial, finally fulfilling the promise that FX has made for easily reskinnable controls, as you no longer lose the default platform behavior.? Then with Behaviors also being replaceable, one can much easier allow for custom behaviors that expose fancy things like?a fully customizable InputMap (although please, let's not make it observable, and let's de-duplicate them). --John On 13/01/2026 18:35, Andy Goryachev wrote: > I agree with Martin that this issue is mostly limited to Controls > because of the skins. ?What was the main objection to the InputMap > idea I proposed? > > I do want to ask Martin one thing though: what do you mean by "The > only obvious gap in the public API is that there?s no way for a > handler or filter to communicate with the dispatcher that invoked it." > ?Can you give an example? > > Thanks! > > -andy > > > *From: *openjfx-dev on behalf of Martin > Fox > *Date: *Tuesday, January 13, 2026 at 09:00 > *To: *John Hendrikx > *Cc: *OpenJFX > *Subject: *Re: [External] : Re: Default event handlers > > I didn?t intend to re-open all of these debates. I just wanted to > point out that JavaFX in general uses dispatchers to process events so > there?s no existing concept of default handlers outside of Control. If > Control had implemented InputMap using a dispatcher we probably > wouldn?t be having this conversation. > > I still believe this is a local problem for Control and it can craft > its own solution. It doesn?t even have to involve handlers; look at > how Scene and Menu handle accelerators. Whatever Control wants to do > almost all of the tools are there. The only obvious gap in the public > API is that there?s no way for a handler or filter to communicate with > the dispatcher that invoked it.?Rather than add a specialized bit like > this PR does I thought it might be worth considering a more > generalized solution (I can think of a few) but I?m actually fine with > preventDefault() since it?s based on an existing standard. > > Martin > > On Jan 13, 2026, at 4:52?AM, John Hendrikx > wrote: > > > On 13/01/2026 00:43, Andy Goryachev wrote: > > > The reason I mentioned #2 is that it is somewhat relevant to > the discussion, as in "why do we need to write custom > dispatchers at all?" ?There should be only two methods, in my > opinion, one that dispatches an event that bubbles up (with > filters and handlers), and one that sends an event to a single > target Node and nothing else. ?Somehow, Swing got the > Events right - it manages to dispatch one (1) event in total, > and the dispatching stops once the event is consumed. ?The?FX > decided it needed to reinvent the wheel and leave multiple > booby traps in the process. > > Although I agree that how FX solved events is sub-optimal, there > is a real need here to communicate to the EventHandler on which > object it resides.? EventHandler instances are expensive when you > need to attach one to every Cell in a TableView, and so to re-use > a single instance, you need to know which Cell the event applies > to.??The source field (which is supposed to be constant) has been > abused for this, making events non-constant requiring cloning > before they can be dispatched to their final target.? This cloning > then caused the "isConsumed" problem.? Perhaps we should just make > the source field mutable as well, so the cloning isn't needed. > > The solution to this problem at the time should not have been to > modify events, but to have made event handlers be BiConsumers, > with the Event **and** Node being passed to the callback (and a > "convenience" method that delegates to the BiConsumer variant that > accepts only Consumer -- we may be able to still do this...) > > > This isn't exactly rocket science, we should be able to figure > something out. ?Maybe there is another option that will > satisfy everyone? > > I think the issue isn't so much in event dispatching, but in the > Skin/Behavior system itself.? Skin/Behaviors in FX is like giving > root access to every user on your system.? Sure it is convenient > that everyone can do whatever they want, and as long as everyone > behaves, everything works great.? However one malicious user can > interfere with others or leave behind hooks that later come to > bite you. > > Controls are HOSTS for Skins and Behaviors.? Skins and Behaviors > are clients.? They should be restricted to a very specific subset > of functionality that benefits the host and is predictable for the > host: > > - Skins get ownership of the children list of the Control; while a > Skin is installed, the host should not be allowed to make > modifications > - Skins can monitor properties for changes but this should never > lead to a direct observable change on the main control that a > subsequent installed listener may observe; in other words, > listener order should be irrelevant for what the Skin does in > order to share the listener infrastructure without interference.? > Skins are free to directly take action on the children (which they > own exclusively), just not on the main control; such actions > should instead be deferred, usually by requesting a layout (this > is usually already the case, but it is good to make this explicit > so we can decide what a Skin is doing is a bug or not). > - Behaviors can react to events at the lowest precedence, and > exclusively only take action when receiving an event; this means > that blocking all events will automatically mean the Behavior no > longer does anything, but also that selectively blocking events > allows some control over Behaviors > - Behaviors can co-modify properties on the Control, but this > should be clearly documented; controls are free to restrict this > set (ie. a Behavior has no business modifying the "wrapText" > property, or things like layout properties -- most often they do > their work through pseudo class changes and modifying the value a > control represents). > > That should really be all that is needed for a functioning > Skin/Behavior system; no need for root access. > > Of course, root access to the Control is a ship that has sailed a > long time ago; but that doesn't mean we can't introduce a client > API for Skins/Behaviors.? All that really takes is passing an > object to the Skin/Behavior when it is installed. This object is > an interface with which the Skin/Behavior can do their work. > Should they choose to not circumvent this API, and do all their > work through this API, they can remove all their clean-up code, as > the Control can now do this automatically.? This will greatly > simplify skins, and remove a whole avenue of potential bugs. > > All work done through this API can be monitored by the Control. > The control can: > - Track what is installed (for later clean-up) > - Reject installation of listeners/handlers it doesn't want to expose > - Ensure that event handlers are installed at lowest precedence.? > This can be kept internal, so many solutions are possible: > separate lists, default event handlers (internal API), priorities, > etc. > > Everything you'd expect a host Control to be able to do, including > forcefully removing all traces of a previously installed Skin, and > disallowing it further access should it attempt to use the API > again after a new Skin is installed. That's however not a > requirement; all we'd need is that interface, and encourage > Skins/Behaviors to use it.? Correctly behaved Skins/Behaviors then > get all the benefits, and will stop interfering with user code.? > This means of course modifications to existing skins, but it is > mostly in their registration logic (which I think we modified like > 5 times already). > > The minimum API needed can be fairly small, and does not need to > include accessors for every property and handler with some smart > signatures.? For example: > > ??? > > *void*?addListener(Function supplier, Consumer subscriber) > > Allows installation of a listener by doing: > > ??? api.addListener(Slider::minProperty, v -> { ... }); > > In this way we can isolate and track what Skins/Behaviors are > doing, ensure they don't interfere with user operations on the > Control and also ensure guaranteed clean-up (if they refrain from > accessing the Control directly). > > --John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zelmidaoui at openjdk.org Tue Jan 13 22:06:11 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 13 Jan 2026 22:06:11 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> References: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> Message-ID: On Mon, 12 Jan 2026 16:28:53 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge branch 'master' into 8371067.request.layout > - 2026 > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - updated test > - Merge branch 'master' into 8371067.request.layout > - add text segment > - Merge branch 'master' into 8371067.request.layout > - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 LGTM, tested in latest standalone MonkeyTester and new test added works fine. ------------- Marked as reviewed by zelmidaoui (Committer). PR Review: https://git.openjdk.org/jfx/pull/1975#pullrequestreview-3658113360 From angorya at openjdk.org Tue Jan 13 22:24:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 22:24:39 GMT Subject: RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v8] In-Reply-To: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> References: <97PxAmo5TFYXXweZDm_GOIbw4KEVSsVUqNYj3s16ED0=.64133fb8-407a-4ea6-8c00-c6534c540ada@github.com> Message-ID: On Mon, 12 Jan 2026 16:28:53 GMT, Andy Goryachev wrote: >> Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. >> >> >> ### NOTES >> >> - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) >> - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest >> >> Screenshot 2025-11-17 at 13 43 12 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - review comments > - Merge branch 'master' into 8371067.request.layout > - 2026 > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - Merge branch 'master' into 8371067.request.layout > - updated test > - Merge branch 'master' into 8371067.request.layout > - add text segment > - Merge branch 'master' into 8371067.request.layout > - ... and 4 more: https://git.openjdk.org/jfx/compare/f7b563c7...d605d6b8 Thank you all for reviewing! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1975#issuecomment-3746822021 From angorya at openjdk.org Tue Jan 13 22:26:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 22:26:38 GMT Subject: Integrated: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow In-Reply-To: References: Message-ID: <36VpGSVYF0DtqFNS-BeGij0_dNvLKmZOV81U__rxVLg=.cfc8f488-c641-4e7b-b826-2a784c6f01d7@github.com> On Mon, 17 Nov 2025 21:46:06 GMT, Andy Goryachev wrote: > Requesting `VFlow` re-layout when signaled by a `Node` embedded in `TextCell`. > > > ### NOTES > > - this PR depends on https://github.com/openjdk/jfx/pull/1974 (resolved) > - the fix can be verified visually using the latest standalone Monkey Tester https://github.com/andy-goryachev-oracle/MonkeyTest > > Screenshot 2025-11-17 at 13 43 12 This pull request has now been integrated. Changeset: e20c0fd6 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/e20c0fd61494322d001131104f92ee5fc5db4626 Stats: 83 lines in 4 files changed: 74 ins; 0 del; 9 mod 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow Reviewed-by: arapte, zelmidaoui ------------- PR: https://git.openjdk.org/jfx/pull/1975 From angorya at openjdk.org Tue Jan 13 22:31:31 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 22:31:31 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: References: Message-ID: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> > Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) > > Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). 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 8374909.exception - limit - lf - whitespace - fix - tests ------------- Changes: https://git.openjdk.org/jfx/pull/2029/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2029&range=02 Stats: 328 lines in 8 files changed: 280 ins; 31 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/2029.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2029/head:pull/2029 PR: https://git.openjdk.org/jfx/pull/2029 From kcr at openjdk.org Tue Jan 13 22:46:15 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 22:46:15 GMT Subject: RFR: 8369836: Update HeaderBar API [v18] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 16:24:42 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > constant name The code changes look good to me. Thanks for documenting some of the trickier aspects of this. So far my manual testing on macOS looks good. In parallel with finishing up a little light testing on Windows and Linux, I am running a headful test on our CI systems. Once all passes, I'll approve. ------------- PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3658212973 From zelmidaoui at openjdk.org Tue Jan 13 22:58:55 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Tue, 13 Jan 2026 22:58:55 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> References: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> Message-ID: On Tue, 13 Jan 2026 22:31:31 GMT, Andy Goryachev wrote: >> Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) >> >> Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). > > 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 8374909.exception > - limit > - lf > - whitespace > - fix > - tests I am not able to reproduce the issue same as in the video : https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 I am using chinese input (Pinyin - Simplified) and typing some text in RTA and click enter or a number (1-2-3-...) have the same result as in a TextField I could be missing something in the steps to reproduce. Tried it in MonkeyTester and a simple app with both RTA and TextField : @Override public void start(Stage stage) { TextField textField = new TextField(); textField.setPromptText("TextField"); RichTextArea richTextArea = new RichTextArea(); richTextArea.setPrefHeight(200); VBox root = new VBox(10, textField, richTextArea); stage.setScene(new Scene(root, 400, 300)); stage.setTitle("TextField + RichTextArea"); stage.show(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/2029#issuecomment-3746933314 From angorya at openjdk.org Tue Jan 13 23:08:44 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 13 Jan 2026 23:08:44 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: References: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> Message-ID: On Tue, 13 Jan 2026 22:55:48 GMT, Ziad El Midaoui wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into 8374909.exception >> - limit >> - lf >> - whitespace >> - fix >> - tests > > I am not able to reproduce the issue same as in the video : https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 > I am using chinese input (Pinyin - Simplified) and typing some text in RTA and click enter or a number (1-2-3-...) have the same result as in a TextField > I could be missing something in the steps to reproduce. > Tried it in MonkeyTester and a simple app with both RTA and TextField : > > @Override > public void start(Stage stage) { > TextField textField = new TextField(); > textField.setPromptText("TextField"); > RichTextArea richTextArea = new RichTextArea(); > richTextArea.setPrefHeight(200); > VBox root = new VBox(10, textField, richTextArea); > stage.setScene(new Scene(root, 400, 300)); > stage.setTitle("TextField + RichTextArea"); > stage.show(); > } @Ziad-Mid you have to make sure that pinyin is active and type in letters (pinyin is a sort of phonetic entry?type "hanzi1" to get ?? ) Screenshot 2026-01-13 at 15 01 52 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2029#issuecomment-3746954815 From kcr at openjdk.org Tue Jan 13 23:46:31 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Jan 2026 23:46:31 GMT Subject: RFR: 8369836: Update HeaderBar API [v18] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 16:24:42 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`. >> >> In addition to that, two new `HeaderDragType` constants are added: >> * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing >> * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > constant name Looks good! All tests pass. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1936#pullrequestreview-3658328976 From mstrauss at openjdk.org Wed Jan 14 00:40:41 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 00:40:41 GMT Subject: Integrated: 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 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`. > > In addition to that, two new `HeaderDragType` constants are added: > * `TRANSPARENT`: when set on a node, excludes the node from draggable-area hit testing > * `TRANSPARENT_SUBTREE`: the same, but also applies to the node's subtree This pull request has now been integrated. Changeset: a3b85676 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/a3b85676cd20741243ed46392320281e45cc5c2f Stats: 1337 lines in 19 files changed: 844 ins; 193 del; 300 mod 8369836: Update HeaderBar API Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1936 From michaelstrau2 at gmail.com Wed Jan 14 02:07:28 2026 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 14 Jan 2026 03:07:28 +0100 Subject: Version support for Windows 10 In-Reply-To: <0F9C34B1-B34E-4214-818E-21F55A86D826@gmail.com> References: <0F9C34B1-B34E-4214-818E-21F55A86D826@gmail.com> Message-ID: I think we could have Windows 10 version 1607 (introduced 2 August 2016) be the minimum supported version, as that's where several APIs that we're using were added. Its longest-term support window closes on 13 October 2026. On Fri, Dec 19, 2025 at 10:38?PM Martin Fox wrote: > > Does JavaFX have a policy regarding support for Windows 10 versions? I?m seeing code come through that jumps through hoops to ensure proper operation on the earliest versions of Windows 10. That dates back more than ten years which exceeds Microsoft?s longest support window (which is targeted at customers who don?t intend to install new software to begin with). > > On the one hand it seems right that we should follow Microsoft?s five-year enterprise window and only support Win10 2021 (21H2) and beyond. On the other hand that would mean ending all Win10 support in JavaFX by 2027 which seems unlikely. There?s a lot of Win10 boxes out there. I imagine most of them are up to date but we could still have a bunch of 21H2 and 22H2 systems floating around for a long time. > > Just maintaining a test environment will become a challenge as the retail channels dry up. What versions are used for running the automated tests currently? > > Martin From mstrauss at openjdk.org Wed Jan 14 02:10:45 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 02:10:45 GMT Subject: RFR: 8372415: Stage size should match visual window bounds [v5] In-Reply-To: References: Message-ID: > On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`. > > Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect. > > For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges): > window-size-1 > > What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders: > window-size-2 > > The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?). Michael Strau? 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 fixes/window-size # Conflicts: # modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp # modules/javafx.graphics/src/main/native-glass/win/GlassWindow.h - Merge branch 'master' into fixes/window-size - return earlier - handle edge cases - add comments - Stage size should match extended frame bounds ------------- Changes: https://git.openjdk.org/jfx/pull/1982/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1982&range=04 Stats: 295 lines in 6 files changed: 242 ins; 16 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/1982.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1982/head:pull/1982 PR: https://git.openjdk.org/jfx/pull/1982 From mstrauss at openjdk.org Wed Jan 14 02:15:37 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 02:15:37 GMT Subject: RFR: 8372415: Stage size should match visual window bounds [v6] In-Reply-To: References: Message-ID: > On Windows, the `Stage.width` and `Stage.height` correspond to the window size as returned by `GetWindowRect`. > > Up until Windows 10, the size of a window was identical to its visual borders. However, since Windows 10 has introduced thin visual window borders, the window manager adds an invisible border of a few pixels around the window to make it easier to resize the window. Since `GetWindowRect` returns the window size _including_ these invisible borders, the location and size of a `Stage` isn't exactly what we'd expect. > > For example, if we place a `Stage` at `setX(0)` and `setY(0)`, the window appears with a small distance from the screen edge, and the window size extends a few pixels beyond its visual borders (in the following images, the screenshot size corresponds to the window size; note the invisible padding around the edges): > window-size-1 > > What we actually want is to have the visual borders line up with the edges of the screen, and have the window size correspond to the visual borders: > window-size-2 > > The implementation is quite simple: instead of `GetWindowRect`, we use `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)`. This gives us the bounds of the visual window borders. If this function fails, we fall back to `GetWindowRect` (now, I don't know why `DwmGetWindowAttribute(DWMA_EXTENDED_FRAME_BOUNDS)` would ever fail... maybe an old Windows version in a remote desktop scenario?). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix merge ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1982/files - new: https://git.openjdk.org/jfx/pull/1982/files/1d439c51..63ef9f3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1982&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1982&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1982.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1982/head:pull/1982 PR: https://git.openjdk.org/jfx/pull/1982 From mstrauss at openjdk.org Wed Jan 14 02:18:49 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 02:18:49 GMT Subject: RFR: 8364149: Conditional stylesheet imports [v2] In-Reply-To: References: Message-ID: > The [`@import`](https://www.w3.org/TR/css-cascade-5/#at-import) rule is extended to support conditional stylesheet imports: > > > @import [ | ] ? ; > > > Conceptually, a conditional import takes all rules of the referenced stylesheet, literally includes them at the location of the `@import` rule, and surrounds them with a `@media` rule with the specified ``. > > The implementation of this feature extends media queries with a context-free evaluation function: > > interface MediaQuery { > TriState evaluate(); // returns TRUE / FALSE / UNKNOWN > } > > > This mode of evaluation uses Kleene's strong trivalent logic to determine whether the media query will always match (it's a tautology), will never match (it's a contradiction), or whether it depends on the context or we simply don't know. > > Using this mechanism, a conditional stylesheet import that can never match will be skipped at runtime. Similarly, a conditional stylesheet import that will always match doesn't need the `` at all; its rules will be pasted verbatim into the main stylesheet. > > Note that this mechanism is _not_ meant to be a full-blown theorem solver. It won't detect that, for example, the following import conditions will always match: > > @import url("stylesheet.css") (width > 1000) or (width <= 1000); > > > Its purpose is an optimization for "obvious" cases. For example, at the moment the built-in themes use hard-coded conditions to include user-agent stylesheets at runtime: > > // in PlatformImpl.java: > if (isSupported(ConditionalFeature.INPUT_TOUCH)) { > uaStylesheets.add("com/sun/javafx/scene/control/skin/modena/touch.css"); > } > > In the future, we might have a way to test for `ConditionalFeature` flags that achieves the same thing, but with a public API available to all theme authors: > > @import url("com/sun/javafx/scene/control/skin/modena/touch.css") > (-fx-supports-conditional-feature: input-touch); 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 two additional commits since the last revision: - Merge branch 'master' into feature/conditional-import - Conditional stylesheet imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2031/files - new: https://git.openjdk.org/jfx/pull/2031/files/3aaab577..12fc8915 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2031&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2031&range=00-01 Stats: 1420 lines in 23 files changed: 918 ins; 193 del; 309 mod Patch: https://git.openjdk.org/jfx/pull/2031.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2031/head:pull/2031 PR: https://git.openjdk.org/jfx/pull/2031 From zelmidaoui at openjdk.org Wed Jan 14 02:57:30 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 14 Jan 2026 02:57:30 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> References: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> Message-ID: <1fZIyvGffzus7TFd_XTLVfTF9zz-33NggGBDJtQAhBU=.adfbdbb1-11b9-4bf0-9c16-5286bde74479@github.com> On Tue, 13 Jan 2026 22:31:31 GMT, Andy Goryachev wrote: >> Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) >> >> Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). > > 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 8374909.exception > - limit > - lf > - whitespace > - fix > - tests Tested and works as expected in MonkeyTester and test app, the tests also works fine. ------------- Marked as reviewed by zelmidaoui (Committer). PR Review: https://git.openjdk.org/jfx/pull/2029#pullrequestreview-3658634350 From mstrauss at openjdk.org Wed Jan 14 03:48:28 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 03:48:28 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) Marked as reviewed by mstrauss (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-3658716297 From mstrauss at openjdk.org Wed Jan 14 03:49:16 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 14 Jan 2026 03:49:16 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation Message-ID: This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. ------------- Commit messages: - javafx.scene.layout package documentation Changes: https://git.openjdk.org/jfx/pull/2035/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375243 Stats: 21 lines in 1 file changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2035.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2035/head:pull/2035 PR: https://git.openjdk.org/jfx/pull/2035 From arapte at openjdk.org Wed Jan 14 07:38:22 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 14 Jan 2026 07:38:22 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> References: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> Message-ID: On Tue, 13 Jan 2026 22:31:31 GMT, Andy Goryachev wrote: >> Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) >> >> Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). > > 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 8374909.exception > - limit > - lf > - whitespace > - fix > - tests lgtm+... Tested with monkey tester. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2029#pullrequestreview-3659286878 From kcr at openjdk.org Wed Jan 14 12:39:09 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 12:39:09 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 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=48169 The original filter, with the backport IDs, is here: https://bugs.openjdk.org/issues/?filter=48168 As usual, I excluded test bugs, cleanup bugs, etc. NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. ------------- Commit messages: - 8375235: Create release notes for JavaFX 25.0.2 Changes: https://git.openjdk.org/jfx25u/pull/43/files Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=43&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375235 Stats: 43 lines in 1 file changed: 43 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx25u/pull/43.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/43/head:pull/43 PR: https://git.openjdk.org/jfx25u/pull/43 From kcr at openjdk.org Wed Jan 14 12:39:10 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 12:39:10 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:34:15 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=48169 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=48168 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. Reviewers: @arapte or @andy-goryachev-oracle @johanvos @tiainen @abhinayagarwal : can one of you take a look as well? ------------- PR Comment: https://git.openjdk.org/jfx25u/pull/43#issuecomment-3749370111 From kevin.rushforth at oracle.com Wed Jan 14 12:57:59 2026 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Jan 2026 04:57:59 -0800 Subject: FINAL REMINDER: JavaFX 26 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 26] In-Reply-To: <22f309a7-d33d-4b27-8f33-fe66454923a0@oracle.com> References: <22f309a7-d33d-4b27-8f33-fe66454923a0@oracle.com> Message-ID: <4c578cf4-8777-4006-bbbc-5b7bb8768aa4@oracle.com> JavaFX 26 RDP1 starts tomorrow, January 15th. I will fork the 'jfx26' branch at 16:00 UTC. -- Kevin On 12/22/2025 4:07 PM, Kevin Rushforth wrote: > As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 26 starts on > Thursday, January 15, 2025 at 16:00 UTC (08:00 US/Pacific time). Given > the upcoming holidays, that's about 2 working weeks from now. > > During rampdown of JavaFX 26, the "master" branch of the jfx repo will > be open for JavaFX 27 fixes. > > Please allow sufficient time for any feature that needs a CSR. New > features should be far enough along in the review process that you can > finalize the CSR no later than Thursday, January 8, or it is likely to > miss the window for this release, in which case it can be targeted for > JavaFX 27. > > We will follow the same process as in previous releases for getting > fixes into JavaFX 26 during rampdown. I'll send a message with > detailed information when we fork, but candidates for fixing during > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc > bugs of any priority. Some small enhancements might be considered > during RDP1, but they require explicit approval; the bar will be high > for such requests. > > -- Kevin > > > On 11/18/2025 6:39 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 26: >> >> RDP1: Jan 15, 2026 (aka ?feature freeze?) >> RDP2: Feb 5, 2026 >> RC: Feb 26, 2026 (aka ?code freeze?) >> GA: Mar 17, 2026 >> >> We will fork a jfx26 stabilization branch at RDP1. >> >> The start of RDP1, the start of RDP2, and the code freeze will be >> 16:00 UTC on the respective dates. >> >> Please let Johan or me know if you have any questions. >> >> -- Kevin >> > From angorya at openjdk.org Wed Jan 14 15:20:54 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 15:20:54 GMT Subject: RFR: 8374909: CodeArea: Exception in IME [v3] In-Reply-To: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> References: <9nyWgWhzc-7NrWN7gdFvehAP6m95CL3dVTLciHgu5q8=.50f8f4c6-e87c-4a57-8d24-fa8f22be80ba@github.com> Message-ID: On Tue, 13 Jan 2026 22:31:31 GMT, Andy Goryachev wrote: >> Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) >> >> Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). > > 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 8374909.exception > - limit > - lf > - whitespace > - fix > - tests Thank you all for reviewing! ------------- PR Comment: https://git.openjdk.org/jfx/pull/2029#issuecomment-3750050798 From angorya at openjdk.org Wed Jan 14 15:20:56 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 15:20:56 GMT Subject: Integrated: 8374909: CodeArea: Exception in IME In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 21:27:31 GMT, Andy Goryachev wrote: > Fixes a bug which was reported in https://github.com/andy-goryachev-oracle/Test/issues/6#issuecomment-3726867016 (introduced by adding IME support https://bugs.openjdk.org/browse/JDK-8368478 ) > > Adds proper clamping and normalization of selection range within the `StyledTextModel`, and replaces the implementation of getText() with the standard export(). This pull request has now been integrated. Changeset: b15d97ee Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b15d97eef51ac88f94e5eccfc1ec40a4df9a06b6 Stats: 328 lines in 8 files changed: 280 ins; 31 del; 17 mod 8374909: CodeArea: Exception in IME Reviewed-by: zelmidaoui, arapte ------------- PR: https://git.openjdk.org/jfx/pull/2029 From angorya at openjdk.org Wed Jan 14 16:48:26 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 16:48:26 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:40:10 GMT, Michael Strau? wrote: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 205: > 203: * {@link javafx.scene.Node#nodeOrientationProperty() Node.nodeOrientation} properties. > 204: * A value set on a {@code Scene} applies to its root, and a value set on any {@code Node} applies to that > 205: * node and its descendants. It is effectively left-to-right by default, but can be right-to-left depending it is effectively -> it is typically? modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 209: > 207: * scene graph, descendants of the scene or node will inherit the specified orientation. > 208: *

> 209: * For layout containers, the effective orientation determines how children are ordered and how horizontal It might be just me, but it feels like very long and hard to understand. Could we just say that for historic reasons, left/right should be interpreted as leading/trailing? and give an example: "left" in RTL mode appears on the right side, sorry about that? what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691211184 PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691220663 From mfox at openjdk.org Wed Jan 14 17:42:18 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 14 Jan 2026 17:42:18 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents Message-ID: Updated documentation for various topics related to keyboard handling. This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. ------------- Commit messages: - Spacing fix and wording change. - Merge remote-tracking branch 'upstream/master' into shortcutdocs - Further wording updates. - Merge remote-tracking branch 'upstream/master' into shortcutdocs - More wording changes. - Merge remote-tracking branch 'upstream/master' into shortcutdocs - Merge remote-tracking branch 'upstream/master' into shortcutdocs - More wording tweaks. - Merge remote-tracking branch 'upstream/master' into shortcutdocs - More work on wording - ... and 2 more: https://git.openjdk.org/jfx/compare/f7b563c7...53594042 Changes: https://git.openjdk.org/jfx/pull/2036/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2036&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341560 Stats: 49 lines in 4 files changed: 33 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/2036.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2036/head:pull/2036 PR: https://git.openjdk.org/jfx/pull/2036 From angorya at openjdk.org Wed Jan 14 18:05:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 18:05:47 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:36:13 GMT, Martin Fox wrote: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. since we are deprecating some constants, I think we need a ------------- PR Comment: https://git.openjdk.org/jfx/pull/2036#issuecomment-3750902571 From angorya at openjdk.org Wed Jan 14 18:38:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 18:38:47 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:36:13 GMT, Martin Fox wrote: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. nicely worded doc changes, thank you! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2036#pullrequestreview-3662219258 From jhendrikx at openjdk.org Wed Jan 14 18:50:19 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Jan 2026 18:50:19 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:40:10 GMT, Michael Strau? wrote: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 214: > 212: * the first child usually appears at the right edge and subsequent children flow to the left. Containers that > 213: * expose named regions keep the same API, but the visual placement is mirrored in right-to-left mode. > 214: * For example, the {@code left} and {@code right} regions of {@link javafx.scene.layout.BorderPane BorderPane} Hm, I didn't know that in the RTL world, the words "left" and "right" change meaning. I checked `BorderPane`, I can't find any evidence for this claim. Is this really the case? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691622120 From angorya at openjdk.org Wed Jan 14 18:50:20 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 18:50:20 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 18:45:00 GMT, John Hendrikx wrote: >> This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. > > modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 214: > >> 212: * the first child usually appears at the right edge and subsequent children flow to the left. Containers that >> 213: * expose named regions keep the same API, but the visual placement is mirrored in right-to-left mode. >> 214: * For example, the {@code left} and {@code right} regions of {@link javafx.scene.layout.BorderPane BorderPane} > > Hm, I didn't know that in the RTL world, the words "left" and "right" change meaning. I checked `BorderPane`, I can't find any evidence for this claim. Is this really the case? yep. try BorderPane page in the monkey tester, set the node orientation to RTL ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691629669 From jhendrikx at openjdk.org Wed Jan 14 18:59:35 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Jan 2026 18:59:35 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 18:47:31 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 214: >> >>> 212: * the first child usually appears at the right edge and subsequent children flow to the left. Containers that >>> 213: * expose named regions keep the same API, but the visual placement is mirrored in right-to-left mode. >>> 214: * For example, the {@code left} and {@code right} regions of {@link javafx.scene.layout.BorderPane BorderPane} >> >> Hm, I didn't know that in the RTL world, the words "left" and "right" change meaning. I checked `BorderPane`, I can't find any evidence for this claim. Is this really the case? > > yep. try BorderPane page in the monkey tester, set the node orientation to RTL I retract the comment. This is certainly well hidden. I'm not sure actually if mirroring literally everything is what a RTL world really desires, but apparently that's the case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691655409 From jhendrikx at openjdk.org Wed Jan 14 19:04:31 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 14 Jan 2026 19:04:31 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:40:10 GMT, Michael Strau? wrote: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. Perhaps add a paragraph about how this works, as developers also sometimes write their own layout code. Apparently, it is handled with a transform or something, so layout code itself is completely oblivious to this (and should be). Developers writing their own code for layout should therefore probably not take node orientation into account or they get the opposite effect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2035#issuecomment-3751135575 From angorya at openjdk.org Wed Jan 14 19:04:32 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 19:04:32 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 18:55:51 GMT, John Hendrikx wrote: >> yep. try BorderPane page in the monkey tester, set the node orientation to RTL > > I retract the comment. This is certainly well hidden. I'm not sure actually if mirroring literally everything is what a RTL world really desires, but apparently that's the case. We could possibly introduce leading/trailing aliases instead of left/right in all the affected places, but apparently the easiest (?) thing is to get used to this historical innacuracy. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2691675058 From kcr at openjdk.org Wed Jan 14 19:17:18 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 19:17:18 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:36:13 GMT, Martin Fox wrote: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. I left an inline comment about needing a `since=27` parameter for the `Deprecated` annotations. As an alternative, you could separate out the deprecations into a follow-on PR for 27, in which case this would become a doc-only PR that could be backported to jfx26. modules/javafx.graphics/src/main/java/javafx/scene/input/KeyCode.java line 625: > 623: * @deprecated Use {@link KeyCode#UP} instead. > 624: */ > 625: @Deprecated Please add a `since` parameter to the `Deprecated` annotations, which is the release in which it is deprecated. Given where we are in the release, this would be `@Deprecated(since = "27")`, since it is too late for an enhancement with a deprecation to get into 26 (unless it were deemed important enough, which this doesn't seem to be). ------------- PR Review: https://git.openjdk.org/jfx/pull/2036#pullrequestreview-3662350209 PR Review Comment: https://git.openjdk.org/jfx/pull/2036#discussion_r2691706806 From angorya at openjdk.org Wed Jan 14 19:45:58 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 19:45:58 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v3] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:10:25 GMT, Christopher Schnick wrote: >> This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. >> >> The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary catch block Looks good, thank you! FYI there is another one https://bugs.openjdk.org/browse/JDK-8201135 which throws a bunch unnecessary exceptions during CSS color parsing, though the fix may not be as trivial. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2032#pullrequestreview-3662336643 From angorya at openjdk.org Wed Jan 14 19:46:02 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 19:46:02 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v3] In-Reply-To: References: Message-ID: <9sjcplPm0G8qvO8Qb7OHjdoTGW3pZQnR-0iUyvc9up4=.7111b471-7f90-4b5a-a4cf-9fd5b93c91ab@github.com> On Mon, 12 Jan 2026 17:19:17 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary catch block > > modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 199: > >> 197: return numberVal.doubleValue(); >> 198: } else if (val != null) { >> 199: Logging.getLogger().warning("Value of select-binding has wrong type, returning default value."); > > minor: I would re-phrase it as something like "Expecting a Number value" (here and elsewhere) Exception message says "expecting XXX" in Bindings, but not here, I am just curious why? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2691695046 From kcr at openjdk.org Wed Jan 14 19:50:34 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 19:50:34 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:45:43 GMT, Christopher Schnick wrote: >> This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. >> >> The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. > > Well that depends on what serious means here. I would consider it serious, so I am moving it to a draft to figure out how to retain the exact behaviour of the old implementation @crschnick As I mentioned above, I don't want to rush this in. Please wait until after tomorrow's jfx26 fork to integrate it, even if there is a second approving reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2032#issuecomment-3751337567 From mfox at openjdk.org Wed Jan 14 20:44:01 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 14 Jan 2026 20:44:01 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents [v2] In-Reply-To: References: Message-ID: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Removed deprecataions. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2036/files - new: https://git.openjdk.org/jfx/pull/2036/files/53594042..94b9cc93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2036&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2036&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/2036.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2036/head:pull/2036 PR: https://git.openjdk.org/jfx/pull/2036 From angorya at openjdk.org Wed Jan 14 20:44:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 20:44:03 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:36:13 GMT, Martin Fox wrote: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. remaining are (minor) javadoc clarifications, CRS is not needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2036#issuecomment-3751609808 From mfox at openjdk.org Wed Jan 14 20:44:06 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 14 Jan 2026 20:44:06 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 19:12:10 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed deprecataions. > > modules/javafx.graphics/src/main/java/javafx/scene/input/KeyCode.java line 625: > >> 623: * @deprecated Use {@link KeyCode#UP} instead. >> 624: */ >> 625: @Deprecated > > Please add a `since` parameter to the `Deprecated` annotations, which is the release in which it is deprecated. Given where we are in the release, this would be `@Deprecated(since = "27")`, since it is too late for an enhancement with a deprecation to get into 26 (unless it were deemed important enough, which this doesn't seem to be). I've removed the deprecations for now. That might be the best thing going forward, references to these constants are benign and there's no point in churning the code to remove them. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2036#discussion_r2691959959 From angorya at openjdk.org Wed Jan 14 20:44:02 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 20:44:02 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:39:39 GMT, Martin Fox wrote: >> Updated documentation for various topics related to keyboard handling. >> >> This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed deprecataions. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2036#pullrequestreview-3662662185 From kcr at openjdk.org Wed Jan 14 21:24:07 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 21:24:07 GMT Subject: RFR: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 20:44:01 GMT, Martin Fox wrote: >> Updated documentation for various topics related to keyboard handling. >> >> This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed deprecataions. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/2036#pullrequestreview-3662818289 From mfox at openjdk.org Wed Jan 14 21:44:58 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 14 Jan 2026 21:44:58 GMT Subject: Integrated: 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 17:36:13 GMT, Martin Fox wrote: > Updated documentation for various topics related to keyboard handling. > > This documentation deprecates the KP_UP, KP_DOWN, KP_LEFT, and KP_RIGHT key codes. As outlined in JDK-8316307 no platform has ever generated these codes and using them with a Robot will produce inconsistent results. This pull request has now been integrated. Changeset: 0a336110 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/0a3361100e3dbd569ca458855e07c0d53aa65ecb Stats: 37 lines in 4 files changed: 29 ins; 0 del; 8 mod 8341560: Better documentation for KeyCombinations/KeyCodes/KeyEvents Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/2036 From duke at openjdk.org Wed Jan 14 21:46:03 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 14 Jan 2026 21:46:03 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent Message-ID: This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. The fix should retain the exact original workings of the method while avoiding the exception. ------------- Commit messages: - Make fix less invasive - Fix OOB Changes: https://git.openjdk.org/jfx/pull/2037/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375227 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2037.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2037/head:pull/2037 PR: https://git.openjdk.org/jfx/pull/2037 From angorya at openjdk.org Wed Jan 14 21:57:15 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 21:57:15 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:54:00 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Wrap expression in parentheses This looks like a localized, safe, and equivalent change. Please wait until after the fork tomorrow to integrate, even if you get all the approvals. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 256: > 254: if (blendMode == Blend.Mode.SRC_OVER || > 255: orderedChildren.size() < 2) { // Blend modes only work "between" siblings > 256: for (int i = startPos == -1 ? 0 : startPos; i < orderedChildren.size(); i++) { very, very minor: Math.max(0, startPos) would work or maybe add parentheses for clarity: int i = (startPos < 0 ? 0 : startPos); upd: I would do startPos < 0 because what if it's -2? :-) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2037#pullrequestreview-3662958971 PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2692183377 From duke at openjdk.org Wed Jan 14 21:57:14 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 14 Jan 2026 21:57:14 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: > This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. > > The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. > > The fix should retain the exact original workings of the method while avoiding the exception. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Wrap expression in parentheses ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2037/files - new: https://git.openjdk.org/jfx/pull/2037/files/65aaaabe..c55f674b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2037&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2037&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2037.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2037/head:pull/2037 PR: https://git.openjdk.org/jfx/pull/2037 From kcr at openjdk.org Wed Jan 14 22:07:48 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 22:07:48 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: <-sm5t5dwuAHfFAE7Kxo99b9PGV3BBEJfIiGJP75N9Pw=.c04d5640-5d24-4d68-ae13-7304abbcad0c@github.com> On Wed, 14 Jan 2026 21:57:14 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Wrap expression in parentheses I'm not sure this is equivalent. Also, I'd like to see a test for this. In general, adding null checks or other similar checks without understanding them is not something we want to do. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2037#pullrequestreview-3663032530 From kcr at openjdk.org Wed Jan 14 22:43:02 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 22:43:02 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: <-sm5t5dwuAHfFAE7Kxo99b9PGV3BBEJfIiGJP75N9Pw=.c04d5640-5d24-4d68-ae13-7304abbcad0c@github.com> References: <-sm5t5dwuAHfFAE7Kxo99b9PGV3BBEJfIiGJP75N9Pw=.c04d5640-5d24-4d68-ae13-7304abbcad0c@github.com> Message-ID: On Wed, 14 Jan 2026 22:04:15 GMT, Kevin Rushforth wrote: > I'm not sure this is equivalent. Also, I'd like to see a test for this. In general, adding null checks or other similar checks without understanding them is not something we want to do. To add a little more to this, replacing code like this: try { // do something } catch (NullPointerException npe) { // log or ignore or ... } with something like this: if (check for null) { // log or ignore or ... } else { // do something } is generally fine and usually easy to prove equivalence. Unless I'm missing something, this PR doesn't do that, rather it takes a state -- startPos == -1 -- that currently causes an OOBE (which is silently ignored) and clamps the value so it will actually do something. That's not equivalent, at least not in all cases. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3752024225 From kcr at openjdk.org Wed Jan 14 22:47:58 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jan 2026 22:47:58 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:57:14 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Wrap expression in parentheses OK, looking at it more closely, I now see why it is equivalent. A comment would probably help. And let us know what you come up with as far as a test goes. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3752036351 From angorya at openjdk.org Wed Jan 14 22:57:48 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 14 Jan 2026 22:57:48 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:57:14 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Wrap expression in parentheses Marked as reviewed by angorya (Reviewer). The original code was just not right, failing to account for a specific case when `orderedChildren` array does not contain `renderRoot.getCurrentNode()` in line 248 there seems to be no ill effects since 2016 (or 2012 when the code was initially open sourced). ------------- PR Review: https://git.openjdk.org/jfx/pull/2037#pullrequestreview-3663203027 PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3752075773 From mstrauss at openjdk.org Thu Jan 15 00:00:18 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 00:00:18 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation [v2] In-Reply-To: References: Message-ID: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2035/files - new: https://git.openjdk.org/jfx/pull/2035/files/32b34361..1d45b701 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2035&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2035&range=00-01 Stats: 16 lines in 1 file changed: 3 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/2035.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2035/head:pull/2035 PR: https://git.openjdk.org/jfx/pull/2035 From mstrauss at openjdk.org Thu Jan 15 00:00:20 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 00:00:20 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: <3_kgXS04MBj7zk5kpXBeFYvVbdXHG6l70D9MaOnuz7k=.f34d0ed9-6ae2-4dcd-93f5-0f70e5b2b4c6@github.com> On Wed, 14 Jan 2026 03:40:10 GMT, Michael Strau? wrote: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. I've changed the wording a bit, maybe that will clear up some things. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2035#issuecomment-3752241882 From angorya at openjdk.org Thu Jan 15 00:03:21 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 00:03:21 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:00:18 GMT, Michael Strau? wrote: >> This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes Marked as reviewed by angorya (Reviewer). modules/javafx.graphics/src/main/java/javafx/scene/layout/package-info.java line 219: > 217: * mode, a mirroring transform is automatically applied to nodes, flipping the visual flow in the horizontal > 218: * direction. If this behavior is not desired, nodes can override {@link javafx.scene.Node#usesMirroring()} > 219: * and return {@code false}. I like it very much, thanks! ------------- PR Review: https://git.openjdk.org/jfx/pull/2035#pullrequestreview-3663352540 PR Review Comment: https://git.openjdk.org/jfx/pull/2035#discussion_r2692484522 From mstrauss at openjdk.org Thu Jan 15 00:09:45 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 00:09:45 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:57:14 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Wrap expression in parentheses modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 259: > 257: NGNode child; > 258: try { > 259: child = orderedChildren.get(i); You should remove the try-catch block as your change ensures that `List.get()` is never called with an invalid index. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2692494209 From mstrauss at openjdk.org Thu Jan 15 00:13:17 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 00:13:17 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:00:18 GMT, Michael Strau? wrote: >> This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes @kevinrushforth Does this need a CSR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2035#issuecomment-3752269214 From duke at openjdk.org Thu Jan 15 02:00:41 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 02:00:41 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:06:12 GMT, Michael Strau? wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrap expression in parentheses > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 259: > >> 257: NGNode child; >> 258: try { >> 259: child = orderedChildren.get(i); > > You should remove the try-catch block as your change ensures that `List.get()` is never called with an invalid index. Judging from the comment below, the catch block was mainly meant to handle concurrent modifications of the list. That scenario might still happen ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2692676781 From jhendrikx at openjdk.org Thu Jan 15 02:50:54 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Jan 2026 02:50:54 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:00:18 GMT, Michael Strau? wrote: >> This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2035#pullrequestreview-3663715936 From mstrauss at openjdk.org Thu Jan 15 03:16:11 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 03:16:11 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties Message-ID: In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: public class InterruptedTransitionBug extends Application { @Override public void start(Stage stage) throws Exception { var root = new StackPane(new Button("My Button")); var scene = new Scene(root, 600, 200); scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" .button { transition: -fx-scale-x 2s; } @media (width > 300px) { .button { -fx-scale-x: 2; } } """.getBytes(StandardCharsets.UTF_8))); stage.setScene(scene); stage.show(); } } ### Problem First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. However, when transitions come into play, this mechanism can break: 1. In our example, the `Button` starts with a style map that contains two properties: * `transition: -fx-scale-x 2s` * `-fx-scale-x: 2` 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: * `transition: -fx-scale-x 2s` 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: * `-fx-scale-x` is reset to `1` * `transition` is reset to `null` This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. ### Solution Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, since the `transition` property is set by both the old and the new style map, we don't reset it: its new value will be calculated in the next `Node.applyCss()` pass. When a property is set by CSS, we also need to make sure that when we ask "has the property actually changed?" we compare the calculated value to the _after-change style_ value of the property, and not to its current (potentially animating) value. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jfx/pull/2038/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375363 Stats: 403 lines in 10 files changed: 357 ins; 16 del; 30 mod Patch: https://git.openjdk.org/jfx/pull/2038.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2038/head:pull/2038 PR: https://git.openjdk.org/jfx/pull/2038 From lbourges at openjdk.org Thu Jan 15 08:58:20 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 15 Jan 2026 08:58:20 GMT Subject: RFR: JDK-8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors Message-ID: merged changes with Java2D bug JDK-8341381 (trivial port on src only) See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 ------------- Commit messages: - merged changes with Java2D bug JDK-8341381 Changes: https://git.openjdk.org/jfx/pull/2039/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2039&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370729 Stats: 58 lines in 4 files changed: 20 ins; 2 del; 36 mod Patch: https://git.openjdk.org/jfx/pull/2039.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2039/head:pull/2039 PR: https://git.openjdk.org/jfx/pull/2039 From lbourges at openjdk.org Thu Jan 15 08:58:20 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 15 Jan 2026 08:58:20 GMT Subject: RFR: JDK-8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:49:18 GMT, Laurent Bourg?s wrote: > merged changes with Java2D bug JDK-8341381 (trivial port on src only) > > See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 @kevinrushforth and @johanvos please review this jfx fix identical to java2d fix, except nearZero() moved into DMarlinRendererPrismUtils ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3753606558 From lbourges at openjdk.org Thu Jan 15 10:17:08 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 15 Jan 2026 10:17:08 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:49:18 GMT, Laurent Bourg?s wrote: > merged changes with Java2D bug JDK-8341381 (trivial port on src only) > > See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 Will fix compilation failure asap (missing module access) ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3753997653 From lbourges at openjdk.org Thu Jan 15 11:18:37 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 15 Jan 2026 11:18:37 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors [v2] In-Reply-To: References: Message-ID: > merged changes with Java2D bug JDK-8341381 (trivial port on src only) > > See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: made Helpers.ulp public to fix compilation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2039/files - new: https://git.openjdk.org/jfx/pull/2039/files/83a13f98..1fa44d9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2039&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2039&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2039.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2039/head:pull/2039 PR: https://git.openjdk.org/jfx/pull/2039 From kcr at openjdk.org Thu Jan 15 13:54:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jan 2026 13:54:01 GMT Subject: RFR: 8375243: Improve javafx.scene.layout package documentation [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 00:09:15 GMT, Michael Strau? wrote: > @kevinrushforth Does this need a CSR? Since the documentation changes clarify existing behavior, and don't call out any exceptions or other restrictions, it doesn't need a CSR. You may integrate it when ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2035#issuecomment-3754976907 From duke at openjdk.org Thu Jan 15 13:59:24 2026 From: duke at openjdk.org (Abhinay Agarwal) Date: Thu, 15 Jan 2026 13:59:24 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:36:03 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=48169 >> >> The original filter, with the backport IDs, is here: >> >> https://bugs.openjdk.org/issues/?filter=48168 >> >> As usual, I excluded test bugs, cleanup bugs, etc. >> >> NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. > > Reviewers: @arapte or @andy-goryachev-oracle > > @johanvos @tiainen @abhinayagarwal : can one of you take a look as well? @kevinrushforth I am not able to access the filters. Did you explicitly filter out https://bugs.openjdk.java.net/browse/JDK-8369820 ? ------------- PR Comment: https://git.openjdk.org/jfx25u/pull/43#issuecomment-3755002972 From kcr at openjdk.org Thu Jan 15 14:00:49 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jan 2026 14:00:49 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 10:14:46 GMT, Laurent Bourg?s wrote: >> merged changes with Java2D bug JDK-8341381 (trivial port on src only) >> >> See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 > > Will fix compilation failure asap (missing module access) @bourgesl Can you create an automated test for this, perhaps derived from the Java2D test in [JDK-8341381](https://bugs.openjdk.org/browse/JDK-8341381)? Reviewers: @kevinrushforth @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3755013488 From kcr at openjdk.org Thu Jan 15 14:05:58 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jan 2026 14:05:58 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:36:03 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=48169 >> >> The original filter, with the backport IDs, is here: >> >> https://bugs.openjdk.org/issues/?filter=48168 >> >> As usual, I excluded test bugs, cleanup bugs, etc. >> >> NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. > > Reviewers: @arapte or @andy-goryachev-oracle > > @johanvos @tiainen @abhinayagarwal : can one of you take a look as well? > @kevinrushforth I am not able to access the filters. Did you explicitly filter out https://bugs.openjdk.java.net/browse/JDK-8369820 ? Sorry about that. It should be visible now. [JDK-8369820](https://bugs.openjdk.java.net/browse/JDK-8369820) is a Task, which we always exclude from release notes. Only issues of type Bug and Enhancement are considered. ------------- PR Comment: https://git.openjdk.org/jfx25u/pull/43#issuecomment-3755053103 From mstrauss at openjdk.org Thu Jan 15 14:07:10 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 14:07:10 GMT Subject: Integrated: 8375243: Improve javafx.scene.layout package documentation In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:40:10 GMT, Michael Strau? wrote: > This PR adds a paragraph about layout orientation to the `javafx.scene.layout` package documentation. This pull request has now been integrated. Changeset: 192929b4 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/192929b47938e3aa03f92947bf72c513414ca845 Stats: 23 lines in 1 file changed: 22 ins; 0 del; 1 mod 8375243: Improve javafx.scene.layout package documentation Reviewed-by: angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/2035 From mstrauss at openjdk.org Thu Jan 15 14:23:21 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 14:23:21 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 01:57:41 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 259: >> >>> 257: NGNode child; >>> 258: try { >>> 259: child = orderedChildren.get(i); >> >> You should remove the try-catch block as your change ensures that `List.get()` is never called with an invalid index. > > Judging from the comment below, the catch block was mainly meant to handle concurrent modifications of the list. That scenario might still happen It does say that, but I don't believe it to be necessary or effective. First of all, there should be no concurrent modifications. The rest of this class assumes this to be true, as `getOrderedChildren()` is iterated over in six other places in the same class, all without wrapping the getter in a try-catch block. Second, you've removed the only scenario where the getter is called with an objectively wrong index (-1), and actually throws an exception. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694566221 From duke at openjdk.org Thu Jan 15 14:23:22 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 14:23:22 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 14:16:12 GMT, Michael Strau? wrote: >> Judging from the comment below, the catch block was mainly meant to handle concurrent modifications of the list. That scenario might still happen > > It does say that, but I don't believe it to be necessary or effective. First of all, there should be no concurrent modifications. The rest of this class assumes this to be true, as `getOrderedChildren()` is iterated over in six other places in the same class, all without wrapping the getter in a try-catch block. Second, you've removed the only scenario where the getter is called with an objectively wrong index (-1), and actually throws an exception. At least this way it is minimally invasive. I think removing the catch block would require more review and testing to be approved as that has the potential of changing the behaviour in edge cases with concurrent modifications, even if other methods don't check for it ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694576739 From fkirmaier at openjdk.org Thu Jan 15 15:09:50 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 15 Jan 2026 15:09:50 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false Message-ID: For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. I've also extended the existing tests for the truncated property. It would be great, to get some feedback on how i fixes the bug. ------------- Commit messages: - JDK-8375444 Changes: https://git.openjdk.org/jfx/pull/2040/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375444 Stats: 100 lines in 2 files changed: 83 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/2040.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2040/head:pull/2040 PR: https://git.openjdk.org/jfx/pull/2040 From mstrauss at openjdk.org Thu Jan 15 15:20:06 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 15:20:06 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 14:19:08 GMT, Christopher Schnick wrote: >> It does say that, but I don't believe it to be necessary or effective. First of all, there should be no concurrent modifications. The rest of this class assumes this to be true, as `getOrderedChildren()` is iterated over in six other places in the same class, all without wrapping the getter in a try-catch block. Second, you've removed the only scenario where the getter is called with an objectively wrong index (-1), and actually throws an exception. > > At least this way it is minimally invasive. I think removing the catch block would require more review and testing to be approved as that has the potential of changing the behaviour in edge cases with concurrent modifications, even if other methods don't check for it Sure, but we're here now, why come back to it later? As you point out, the code has been like that for 10 years, so there's no need for a "quick" fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694799800 From angorya at openjdk.org Thu Jan 15 15:24:41 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 15:24:41 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 14:19:08 GMT, Christopher Schnick wrote: >> It does say that, but I don't believe it to be necessary or effective. First of all, there should be no concurrent modifications. The rest of this class assumes this to be true, as `getOrderedChildren()` is iterated over in six other places in the same class, all without wrapping the getter in a try-catch block. Second, you've removed the only scenario where the getter is called with an objectively wrong index (-1), and actually throws an exception. > > At least this way it is minimally invasive. I think removing the catch block would require more review and testing to be approved as that has the potential of changing the behaviour in edge cases with concurrent modifications, even if other methods don't check for it I agree with @crschnick here: the comment in question, `// minimal protection against concurrent update of the list.` is worrisome, and removing the try-catch block would turn it into a non-equivalent change that might need further review and testing since it might cause regression. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694816022 From angorya at openjdk.org Thu Jan 15 15:26:45 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 15:26:45 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:04:13 GMT, Florian Kirmaier wrote: > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledImpl.java line 61: > 59: > 60: labeledImpl.textTruncatedProperty().subscribe(v -> { > 61: LabeledHelper.setTextTruncated(labeled, v); should the property be bound instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2694826329 From fkirmaier at openjdk.org Thu Jan 15 15:31:49 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 15 Jan 2026 15:31:49 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:23:14 GMT, Andy Goryachev wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledImpl.java line 61: > >> 59: >> 60: labeledImpl.textTruncatedProperty().subscribe(v -> { >> 61: LabeledHelper.setTextTruncated(labeled, v); > > should the property be bound instead? This is going through the Accessor pattern of Labeled. I could extend it, to return the BooleanProperty and use it. Should i? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2694851765 From duke at openjdk.org Thu Jan 15 15:32:36 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 15:32:36 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:20:27 GMT, Andy Goryachev wrote: >> At least this way it is minimally invasive. I think removing the catch block would require more review and testing to be approved as that has the potential of changing the behaviour in edge cases with concurrent modifications, even if other methods don't check for it > > I agree with @crschnick here: the comment in question, `// minimal protection against concurrent update of the list.` is worrisome, and removing the try-catch block would turn it into a non-equivalent change that might need further review and testing since it might cause regression. This PR fixes the performance issue associated with the exceptions. Because there will be multiple exceptions thrown in short succession here, this should actually be a noticeable improvement. After that issue is fixed, you are still left with code of quite bad quality with confusing exception handling, yes, but that is in line with the rest of the older codebase. It's not like this is an isolated instance, the same method has some unnecessary checks further down as well that my IDE correctly flags as not needed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694836499 From angorya at openjdk.org Thu Jan 15 15:32:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 15:32:38 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:16:24 GMT, Michael Strau? wrote: >> At least this way it is minimally invasive. I think removing the catch block would require more review and testing to be approved as that has the potential of changing the behaviour in edge cases with concurrent modifications, even if other methods don't check for it > > Sure, but we're here now, why come back to it later? As you point out, the code has been like that for 10 years, so there's no need for a "quick" fix. @mstr2 we could address this investigation in a follow-up. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694841680 From mstrauss at openjdk.org Thu Jan 15 15:32:39 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 15:32:39 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:27:03 GMT, Andy Goryachev wrote: >> Sure, but we're here now, why come back to it later? As you point out, the code has been like that for 10 years, so there's no need for a "quick" fix. > > @mstr2 we could address this investigation in a follow-up. Yes, but why not do the review and testing? We don't need to rush this change in, as there's no observable defect that's being fixed with this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2694850440 From angorya at openjdk.org Thu Jan 15 15:37:16 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 15:37:16 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:29:14 GMT, Florian Kirmaier wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledImpl.java line 61: >> >>> 59: >>> 60: labeledImpl.textTruncatedProperty().subscribe(v -> { >>> 61: LabeledHelper.setTextTruncated(labeled, v); >> >> should the property be bound instead? > > This is going through the Accessor pattern of Labeled. > I could extend it, to return the BooleanProperty and use it. > Should i? oh, right, I forgot it's a read-only property (and I should know). let me take a look, at first glance it looks right. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2694871584 From duke at openjdk.org Thu Jan 15 15:37:58 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 15:37:58 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: References: Message-ID: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> > This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. > > The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. > > The fix should retain the exact original workings of the method while avoiding the exception. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2037/files - new: https://git.openjdk.org/jfx/pull/2037/files/c55f674b..005d73a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2037&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2037&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2037.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2037/head:pull/2037 PR: https://git.openjdk.org/jfx/pull/2037 From kcr at openjdk.org Thu Jan 15 16:06:27 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jan 2026 16:06:27 GMT Subject: Integrated: 8375067: Change JavaFX release version to 27 In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:35:09 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 27. I will integrate this to master as part of forking the `jfx26` stabilization branch, which is scheduled for Thursday, January 15, 2026 at 16:00 UTC. This pull request has now been integrated. Changeset: 66df38df Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/66df38dfc4948ff954793af3ccb984475f8c1831 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8375067: Change JavaFX release version to 27 Reviewed-by: angorya, jvos ------------- PR: https://git.openjdk.org/jfx/pull/2033 From angorya at openjdk.org Thu Jan 15 16:10:43 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 16:10:43 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2037#pullrequestreview-3666402083 From kevin.rushforth at oracle.com Thu Jan 15 16:23:26 2026 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 15 Jan 2026 08:23:26 -0800 Subject: JavaFX 26 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 26 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx26 branch [2] for stabilizing the JavaFX 26 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for jfx27. Almost all fixes will be integrated to master for 27, even those intended to be fixed in 26. - The jfx26 branch of the jfx repo is now open for integrating fixes for jfx26 that meet the RDP1 criteria as outlined below. As with the previous release, in this release we will integrate almost all stabilization changes via backports from the master branch [3]. ? * Almost all fixes intended for the jfx26 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [4].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx26 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx26. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx26 branch. The master branch is open for all jfx27 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [5] rather than a separate stabilization repo. The jfx26 branch is used to stabilize the upcoming jfx26 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx26 to ensure that it doesn't contain any commits from master after the jfx26 fork date. What that means is that if you intend a PR to be for jfx26, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 27 as of today). This is usually what we want. A backport PR should be targeted to `jfx26` if, and only if, it is intended for JavaFX 26 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx26`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 27. Reviewers also need to be extra careful when reviewing PRs targeted to jfx26 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx26 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. We will use the same rules for RDP1 that the JDK uses [6], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 26 release. As an obvious choice, derived from the JBS fix version, we will use "jfx26-enhancement-request", "jfx26-enhancement-yes", "jfx26-enhancement-no" and "jfx26-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx26 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should only go into master for jfx27, since we do not want to risk anything that would destabilize the jfx26 release without a compelling reason. Also, we have only 3 weeks until RDP2 of jfx26 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for jfx26 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-November/057615.html [2] https://github.com/openjdk/jfx/tree/jfx26 [3] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [4] https://openjdk.org/guide/#working-with-backports-in-jbs [5] https://github.com/openjdk/jfx/branches/all [6] http://openjdk.org/jeps/3 From jhendrikx at openjdk.org Thu Jan 15 16:47:28 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Jan 2026 16:47:28 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v5] 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 with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into feature/in-layoutchildren-detection-for-node - Rename test - Add regression test - 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. - Change how Node detects whether a relayout is required 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. ------------- Changes: https://git.openjdk.org/jfx/pull/1945/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1945&range=04 Stats: 180 lines in 3 files changed: 133 ins; 20 del; 27 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 angorya at openjdk.org Thu Jan 15 17:08:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 17:08:39 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:28:57 GMT, Michael Strau? wrote: >> @mstr2 we could address this investigation in a follow-up. > > Yes, but why not do the review and testing? We don't need to rush this change in, as there's no observable defect that's being fixed with this PR. I would say it out of scope for this PR, which addresses unnecessarily thrown exception. Going deeper might entail further refactoring or redesign, which is better to do in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2695230360 From angorya at openjdk.org Thu Jan 15 17:08:52 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 17:08:52 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:04:13 GMT, Florian Kirmaier wrote: > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. Behaves as expected, the implementation looks good (thanks to `Subscription`). Minor comments, will re-approve if you make changes. For reviewers: added "text truncated" indicator to all controls that extend Labeled, grab the latest here: https://github.com/andy-goryachev-oracle/MonkeyTest modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledImpl.java line 64: > 62: }); > 63: > 64: extra newline? modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 29: > 27: import static org.junit.jupiter.api.Assertions.assertFalse; > 28: import static org.junit.jupiter.api.Assertions.assertTrue; > 29: please change the copyright year * Copyright (c) 2024, 2026, Oracle and/or its affiliates. All rights reserved. modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 100: > 98: testTextProperty(fun.get()); > 99: } > 100: extra newline? modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 177: > 175: > 176: assertFalse(control.isTextTruncated()); > 177: extra newline? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2040#pullrequestreview-3666580782 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2695193713 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2695156919 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2695154196 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2695153262 From duke at openjdk.org Thu Jan 15 17:25:44 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 17:25:44 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment So I looked into the tests. Even in terms of manual testing, this would still require using a debugger and breakpoints to see if the issues is fixed. I'm not sure whether this could still be considered a manual test if it involves that kind of setup With the reproduction instructions of the linked JBS issue, this should always be testable for someone looking to test whether this fix works. The code from the monkey tester system info window perfectly manages to reproduce it. I updated the reproduction instructions a bit to make it more clear when it happens ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3756019642 From angorya at openjdk.org Thu Jan 15 17:25:51 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 17:25:51 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:28:57 GMT, Michael Strau? wrote: >> @mstr2 we could address this investigation in a follow-up. > > Yes, but why not do the review and testing? We don't need to rush this change in, as there's no observable defect that's being fixed with this PR. having said that, I do agree with @mstr2 that sometimes it makes sense to do a little unrelated cleanup when one touches a file, as long as it's safe and obvious. but it is always met with arguments like "what if it needs to be backported or creates a merge conflict" so it gets always shot down. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2695273783 From kcr at openjdk.org Thu Jan 15 17:41:24 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 15 Jan 2026 17:41:24 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:17:48 GMT, Andy Goryachev wrote: >> Yes, but why not do the review and testing? We don't need to rush this change in, as there's no observable defect that's being fixed with this PR. > > having said that, I do agree with @mstr2 that sometimes it makes sense to do a little unrelated cleanup when one touches a file, as long as it's safe and obvious. but it is always met with arguments like "what if it needs to be backported or creates a merge conflict" so it gets always shot down. I agree it seems better to limit the scope of this fix. I can certainly see the argument for expanding the fix to include the now-possibly-unnecessary try/catch (after all, removing one case where it is known to throw and thus be needed is what this fix does), but I'd rather keep the scope limited for this PR. As an off-topic note, I am opposed to cleaning up truly unrelated things that you just happen to notice while you are in the neighborhood, but Michael's request isn't this case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2037#discussion_r2695337785 From duke at openjdk.org Thu Jan 15 17:47:46 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 17:47:46 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v4] In-Reply-To: References: Message-ID: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Improve log messages and fix more catch blocks in SelectBinding ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2032/files - new: https://git.openjdk.org/jfx/pull/2032/files/70377bde..6da3fd16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=02-03 Stats: 20 lines in 1 file changed: 3 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From duke at openjdk.org Thu Jan 15 17:51:27 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 17:51:27 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v4] In-Reply-To: <9sjcplPm0G8qvO8Qb7OHjdoTGW3pZQnR-0iUyvc9up4=.7111b471-7f90-4b5a-a4cf-9fd5b93c91ab@github.com> References: <9sjcplPm0G8qvO8Qb7OHjdoTGW3pZQnR-0iUyvc9up4=.7111b471-7f90-4b5a-a4cf-9fd5b93c91ab@github.com> Message-ID: On Wed, 14 Jan 2026 19:08:10 GMT, Andy Goryachev wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 199: >> >>> 197: return numberVal.doubleValue(); >>> 198: } else if (val != null) { >>> 199: Logging.getLogger().warning("Value of select-binding has wrong type, returning default value."); >> >> minor: I would re-phrase it as something like "Expecting a Number value" (here and elsewhere) > > Exception message says "expecting XXX" in Bindings, but not here, I am just curious why? I updated the log messages in SelectBinding to be consistent with the others ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695381928 From fkirmaier at openjdk.org Thu Jan 15 18:12:13 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 15 Jan 2026 18:12:13 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v2] In-Reply-To: References: Message-ID: <5Ybsh7PwcIgivkRWvEduJBDnQ9nMekynzDIW4sVDyYo=.293f2f58-b14e-4d1d-aef5-3d727cb50459@github.com> > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8375444 Small code formatting fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2040/files - new: https://git.openjdk.org/jfx/pull/2040/files/6ee4ed66..1701bdcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2040.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2040/head:pull/2040 PR: https://git.openjdk.org/jfx/pull/2040 From fkirmaier at openjdk.org Thu Jan 15 18:12:22 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 15 Jan 2026 18:12:22 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 15:04:13 GMT, Florian Kirmaier wrote: > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. Thank you for the quick feedback! I did the small formatting changes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2040#issuecomment-3756195554 From angorya at openjdk.org Thu Jan 15 18:28:21 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 18:28:21 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v2] In-Reply-To: <5Ybsh7PwcIgivkRWvEduJBDnQ9nMekynzDIW4sVDyYo=.293f2f58-b14e-4d1d-aef5-3d727cb50459@github.com> References: <5Ybsh7PwcIgivkRWvEduJBDnQ9nMekynzDIW4sVDyYo=.293f2f58-b14e-4d1d-aef5-3d727cb50459@github.com> Message-ID: On Thu, 15 Jan 2026 18:12:13 GMT, Florian Kirmaier wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8375444 > Small code formatting fixes Marked as reviewed by angorya (Reviewer). modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 122: > 120: testWithSkin(fun.get()); > 121: testTextProperty(fun.get()); > 122: extra newline? sorry, missed it earlier ------------- PR Review: https://git.openjdk.org/jfx/pull/2040#pullrequestreview-3666994923 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2695489180 From mstrauss at openjdk.org Thu Jan 15 18:36:26 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 18:36:26 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: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> On Wed, 7 Jan 2026 21:21:14 GMT, John Hendrikx wrote: > This is why IMHO any layout that relies on convergence is already broken; it just happens to broken in a way that eventually leads to a stable result... A single top-down layout pass only works when the layout constraints are acyclic. However, JavaFX expressly supports cyclic constraints, so the layout system can't chicken out. As soon as there's a cyclic dependency (parent layout is constrained by child, child layout is constrained by parent), you've got a fixed-point problem and need to solve it in some form, for example with multiple layout phases or iteration. Cyclic dependencies can appear in several situations: * CSS/layout coupling: styling influences sizing, sizing influences styling * Parent size depends on child size * Child wraps based on parent width * Baseline alignment * ... Looking at how other frameworks do this, we see that WPF and Android use two layout phases: a constraint-carrying measurement pass (given some available size constraint, how much space would each node like to have?), and a second arrange pass that authoritatively tells each node how much space it is given. Such a system can break some cycles, especially the kind where parent and child sizes mutually constrain each other. It's not a catch-all solution; there can be higher-level cycles, for example with a scroll bar that, upon appearing, causes the layout to reflow, which then again influences the scroll bar. Android detects relayout requests during the layout phase, and will allow for one additional round of measure+layout in the same frame; if a second relayout request is encountered, it is deferred to the next frame. In JavaFX, we don't have two phases of layout to break the easier cycles, and we don't have multiple rounds of layout. I think it is obvious that we need to do something about that, and pretending that cyclic constraints don't exist is not that. What I believe can work for JavaFX is a layout system that basically does this for each frame: while (!layoutClean) { doCssPass(); doLayoutPass(); } If this doesn't settle in a very small number of iterations (something like 3), we can do the remainder of the work in subsequent frames to prevent unresponsive applications. Maybe we can even detect oscillations (e.g. scroll bar flip-flop) and suspend layout in these cases. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3756305694 From duke at openjdk.org Thu Jan 15 18:39:01 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 18:39:01 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Fix failing tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2032/files - new: https://git.openjdk.org/jfx/pull/2032/files/6da3fd16..695c4da7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=03-04 Stats: 7 lines in 2 files changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From angorya at openjdk.org Thu Jan 15 18:45:25 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 18:45:25 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:39:01 GMT, Christopher Schnick wrote: >> This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. >> >> The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing tests Changes requested by angorya (Reviewer). modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 97: > 95: // The type returned might be wrong, but this would not throw any ClassCastException here > 96: // Any casting issue would happen outside this method > 97: return (T) observable.getValue(); so this is NOT an equivalent change, and therefore would need a deeper analysis - I, for example, can't tell if this change makes sense or not right away. Some objects' `toString()` value may not make sense. I would suggest to revert this change to keep the PR at the "light optimization" level. ------------- PR Review: https://git.openjdk.org/jfx/pull/2032#pullrequestreview-3667058234 PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695540780 From angorya at openjdk.org Thu Jan 15 18:56:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 18:56:47 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> Message-ID: <5ZYq7Wo9-l2IGyBU-xjKlhHcIpVH0IExMgGPXW735l0=.35bfeef2-08ae-457c-9c7c-75e85ef70d07@github.com> On Thu, 15 Jan 2026 18:32:39 GMT, Michael Strau? wrote: > for example with multiple layout phases or iteration. That's exactly right. To illustrate, I can point to `VFlow:1545` and `VFlow:1559` where a change in either scroll bar visibility triggers `layoutCells()`. It is the responsibility of the developer of such a component to ensure that the layout converges, i.e. that the logic does not cause infinite recursion. In the `VFlow` case, it does not - once the vertical scrollbar is determined to have shown up, it cannot disappear; same goes for the horizontal scrollbar afterwards. Speaking of the layout system snippet, I might suggest limiting the fast loop to a few iterations only. to guard against locking up: if(!layoutClean) { int fastSteps = 2; // or 3, no more for(int i=0; i References: Message-ID: On Thu, 15 Jan 2026 03:11:11 GMT, Michael Strau? wrote: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... Without this PR, the behavior is even stranger: if the window contains two buttons, to reducing the width below the threshold causes the first button to snap to the original size, but the second button continues the transition: Screenshot 2026-01-15 at 10 59 16 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2038#issuecomment-3756403388 From mstrauss at openjdk.org Thu Jan 15 19:17:24 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 19:17:24 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties In-Reply-To: References: Message-ID: <0g7VzYIWyyoX77lvFnDJT_iZn6AQnV5KyZ8wSt3Ypes=.15ef0dbf-6e04-49d1-8fd3-0e7caad97ad8@github.com> On Thu, 15 Jan 2026 19:01:31 GMT, Andy Goryachev wrote: > Without this PR, the behavior is even stranger: if the window contains two buttons, to reducing the width below the threshold causes the first button to snap to the original size, but the second button continues the transition: I think that's because the CSS-set values are stored in a `HashMap`, and they are reset by iterating over its entries. Since the iteration order of a `HashSet` is undefined, you sometimes can get the `transition` property to be reset before `-fx-scale-x`, and sometimes after it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2038#issuecomment-3756434464 From angorya at openjdk.org Thu Jan 15 19:17:24 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 19:17:24 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties In-Reply-To: <0g7VzYIWyyoX77lvFnDJT_iZn6AQnV5KyZ8wSt3Ypes=.15ef0dbf-6e04-49d1-8fd3-0e7caad97ad8@github.com> References: <0g7VzYIWyyoX77lvFnDJT_iZn6AQnV5KyZ8wSt3Ypes=.15ef0dbf-6e04-49d1-8fd3-0e7caad97ad8@github.com> Message-ID: <38usNtqXZB8gFt2xqqcevAl5_Ow88H5kcMMxVhYdsWk=.8dfd1d85-8d63-4710-9693-691f700b7d2a@github.com> On Thu, 15 Jan 2026 19:10:29 GMT, Michael Strau? wrote: > you sometimes can get the `transition` property to be reset Do you think that can cause some other problematic scenario? With the fix, the behavior is as expected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2038#issuecomment-3756444220 From jhendrikx at openjdk.org Thu Jan 15 19:28:45 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Jan 2026 19:28:45 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> Message-ID: On Thu, 15 Jan 2026 18:32:39 GMT, Michael Strau? wrote: > > This is why IMHO any layout that relies on convergence is already broken; it just happens to broken in a way that eventually leads to a stable result... > > A single top-down layout pass only works when the layout constraints are acyclic. However, JavaFX expressly supports cyclic constraints, so the layout system can't chicken out. As soon as there's a cyclic dependency (parent layout is constrained by child, child layout is constrained by parent), you've got a fixed-point problem and need to solve it in some form, for example with multiple layout phases or iteration. > > Cyclic dependencies can appear in several situations: > > * CSS/layout coupling: styling influences sizing, sizing influences styling > * Parent size depends on child size > * Child wraps based on parent width > * Baseline alignment > * ... Are you referring to media queries for the window size when you say that sizing can influence styling? The others can be resolved similar to how `ScrollPane` does this (see below). > Looking at how other frameworks do this, we see that WPF and Android use two layout phases: a constraint-carrying measurement pass (given some available size constraint, how much space would each node like to have?), and a second arrange pass that authoritatively tells each node how much space it is given. I would say that there's also two passes in FX, although less obvious. The first pass is basically the calling of the compute methods. These cascade down all the way down to the leaf level as each compute will call child compute methods (but can use cached results) before any layout methods are called (apart from the root one). I'm not sure what that pass should be called, but it does sound a lot like what WPF is doing. Only after this does the layout pass cascade down again via the layout calls. This is why some layout problems can sometimes be solved by overriding a compute method and doing some unorthodox work there (for which the correct mechanism is to install a pre-layout listener). > Such a system can break some cycles, especially the kind where parent and child sizes mutually constrain each other. It's not a catch-all solution; there can be higher-level cycles, for example with a scroll bar that, upon appearing, causes the layout to reflow, which then again influences the scroll bar. `ScrollPane` handles that in one pass. Basically it computes the size of the children, and if it determines there is need of a scroll bar, it does those calculations again (which can result in the appearance of the 2nd scrollbar, and the calculations are repeated one more time; this is quite visible in `ScrollPaneSkin`). In effect, it solves this problem internally without waiting for another layout pass, as compute methods can be called as often as desired. > Android detects relayout requests during the layout phase, and will allow for one additional round of measure+layout in the same frame; if a second relayout request is encountered, it is deferred to the next frame. > > In JavaFX, we don't have two phases of layout to break the easier cycles, and we don't have multiple rounds of layout. I think it is obvious that we need to do something about that, and pretending that cyclic constraints don't exist is not that. > > What I believe can work for JavaFX is a layout system that basically does this for each frame: > > ```java > while (!layoutClean) { > doCssPass(); > doLayoutPass(); > } > ``` > > If this doesn't settle in a very small number of iterations (something like 3), we can do the remainder of the work in subsequent frames to prevent unresponsive applications. Maybe we can even detect oscillations (e.g. scroll bar flip-flop) and suspend layout in these cases. I think doing a loop of layout passes up to a limit is fine, although I'm not sure if CSS needs to take part in that. One should not be changing styles during layout, that's a pre-layout concern (which is before CSS runs) and not something to do in the `compute` chain of methods nor the `layoutChildren` methods. Of course, JavaFX being very unrestrictive, one can easily fiddle with CSS during layout calls, and create bad layouts, which hopefully converge, but at some point there is **nothing** that can be done. As these problems tend to be very visible, they're usually fixed quickly, unlike converging layouts which escape notice. This is why I think we should warn when certain actions are taken during layout. A layout that converges now, may stop converging when say `modena.css` is updated or replaced. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3756499809 From duke at openjdk.org Thu Jan 15 19:32:56 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 19:32:56 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:41:33 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing tests > > modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 97: > >> 95: // The type returned might be wrong, but this would not throw any ClassCastException here >> 96: // Any casting issue would happen outside this method >> 97: return (T) observable.getValue(); > > so this is NOT an equivalent change, and therefore would need a deeper analysis - I, for example, can't tell if this change makes sense or not right away. Some objects' `toString()` value may not make sense. > > I would suggest to revert this change to keep the PR at the "light optimization" level. I really didn't look into it that deeply, but from my understanding, there can't be an exception thrown for such a generic cast at runtime. At least not in the method itself. The class cast exception would happen at some point later after this method returns. But I am not an expert on generics. I am not sure what you mean by the toString() comment though ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695681118 From angorya at openjdk.org Thu Jan 15 19:37:02 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 19:37:02 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 19:29:52 GMT, Christopher Schnick wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java line 97: >> >>> 95: // The type returned might be wrong, but this would not throw any ClassCastException here >>> 96: // Any casting issue would happen outside this method >>> 97: return (T) observable.getValue(); >> >> so this is NOT an equivalent change, and therefore would need a deeper analysis - I, for example, can't tell if this change makes sense or not right away. Some objects' `toString()` value may not make sense. >> >> I would suggest to revert this change to keep the PR at the "light optimization" level. > > I really didn't look into it that deeply, but from my understanding, there can't be an exception thrown for such a generic cast at runtime. At least not in the method itself. The class cast exception would happen at some point later after this method returns. But I am not an expert on generics. > > I am not sure what you mean by the toString() comment though I meant classname at hashcode, like "java.lang.Object at 36f6e879" may not be what you expect from `.get()`. A `null` value is the original behavior. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695689040 From mstrauss at openjdk.org Thu Jan 15 19:38:34 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 19:38:34 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties In-Reply-To: <38usNtqXZB8gFt2xqqcevAl5_Ow88H5kcMMxVhYdsWk=.8dfd1d85-8d63-4710-9693-691f700b7d2a@github.com> References: <0g7VzYIWyyoX77lvFnDJT_iZn6AQnV5KyZ8wSt3Ypes=.15ef0dbf-6e04-49d1-8fd3-0e7caad97ad8@github.com> <38usNtqXZB8gFt2xqqcevAl5_Ow88H5kcMMxVhYdsWk=.8dfd1d85-8d63-4710-9693-691f700b7d2a@github.com> Message-ID: <3F6GulqSd9Ixg_FDBXWNdDOLJaSv0987o97FkjwWqnE=.2e59d828-7d28-4c16-a56c-fc538a410048@github.com> On Thu, 15 Jan 2026 19:13:19 GMT, Andy Goryachev wrote: > > you sometimes can get the `transition` property to be reset > > Do you think that can cause some other problematic scenario? > > With the fix, the behavior is as expected. I don't think so: the other part of this fix is to elide unnecessary resets in the first place. So whenever a property is set to A in one style state, and to B in another style state, you won't see a transient "null" value; instead, you'll only see the A->B change if you observe the property. If anything, I think this _reduces_ the chance for problems arising from transient values that are neither A nor B. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2038#issuecomment-3756541410 From duke at openjdk.org Thu Jan 15 19:42:32 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 19:42:32 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 19:32:54 GMT, Andy Goryachev wrote: >> I really didn't look into it that deeply, but from my understanding, there can't be an exception thrown for such a generic cast at runtime. At least not in the method itself. The class cast exception would happen at some point later after this method returns. But I am not an expert on generics. >> >> I am not sure what you mean by the toString() comment though > > I meant classname at hashcode, like "java.lang.Object at 36f6e879" may not be what you expect from `.get()`. A `null` value is the original behavior. I am confused. Are you commenting on the right part of the diff? I don't see anything related to strings in this part ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695704763 From duke at openjdk.org Thu Jan 15 19:48:00 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 19:48:00 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: Message-ID: <9O0PjqkxndeuLXsrXz9WIYlk3I32MgaEuhQ6mRMbGbU=.e865939f-3ad1-4e23-98af-ac8f382e9f2f@github.com> On Thu, 15 Jan 2026 19:38:18 GMT, Christopher Schnick wrote: >> I meant classname at hashcode, like "java.lang.Object at 36f6e879" may not be what you expect from `.get()`. A `null` value is the original behavior. > > I am confused. Are you commenting on the right part of the diff? I don't see anything related to strings in this part Ah, I think I know what you mean now. Since this is about the handling of generics, the original catch block should never be reached in my understanding. The generic T type is erased, meaning this method should always return the value, regardless of whether the type matches or not. If you do assign the return value of this method to a String, and the returned value is not of type string, it will always throw a ClassCastException. But that should also happen for the old method with the catch block. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2695723976 From angorya at openjdk.org Thu Jan 15 19:51:45 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 19:51:45 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties In-Reply-To: References: Message-ID: <9_tZofmC0aAjqLBVH5Opz2Ul8qhxW08TcFM2kWv7IX0=.7f067e2b-fa68-4c4e-af9d-b0a7ce9ddb50@github.com> On Thu, 15 Jan 2026 03:11:11 GMT, Michael Strau? wrote: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... Marked as reviewed by angorya (Reviewer). modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 57: > 55: StyleablePropertyHelper.setBooleanAccessor(new StyleablePropertyHelper.Accessor() { > 56: @Override > 57: public boolean equalsAfterChangeStyleValue(StyleableProperty property, Object value) { minor: would it be slightly more organized to call a private instance method of the property class from each accessor? I think the code is ok, it's just adds so much nearly identical code that bothers me, though I can't figure out a way to avoid the `Accessor` pattern here, package protected methods would not work, would they? ------------- PR Review: https://git.openjdk.org/jfx/pull/2038#pullrequestreview-3667269954 PR Review Comment: https://git.openjdk.org/jfx/pull/2038#discussion_r2695711152 From mstrauss at openjdk.org Thu Jan 15 19:54:39 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 19:54:39 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v2] In-Reply-To: References: Message-ID: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: shorter method name ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2038/files - new: https://git.openjdk.org/jfx/pull/2038/files/8a263f81..07c31411 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=00-01 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jfx/pull/2038.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2038/head:pull/2038 PR: https://git.openjdk.org/jfx/pull/2038 From mstrauss at openjdk.org Thu Jan 15 20:07:43 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 20:07:43 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v3] In-Reply-To: References: Message-ID: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: private equalsEndValue() implementation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2038/files - new: https://git.openjdk.org/jfx/pull/2038/files/07c31411..a677800e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=01-02 Stats: 123 lines in 7 files changed: 57 ins; 59 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/2038.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2038/head:pull/2038 PR: https://git.openjdk.org/jfx/pull/2038 From mstrauss at openjdk.org Thu Jan 15 20:07:46 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 20:07:46 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v3] In-Reply-To: <9_tZofmC0aAjqLBVH5Opz2Ul8qhxW08TcFM2kWv7IX0=.7f067e2b-fa68-4c4e-af9d-b0a7ce9ddb50@github.com> References: <9_tZofmC0aAjqLBVH5Opz2Ul8qhxW08TcFM2kWv7IX0=.7f067e2b-fa68-4c4e-af9d-b0a7ce9ddb50@github.com> Message-ID: On Thu, 15 Jan 2026 19:40:45 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> private equalsEndValue() implementation > > modules/javafx.graphics/src/main/java/javafx/css/StyleableBooleanProperty.java line 57: > >> 55: StyleablePropertyHelper.setBooleanAccessor(new StyleablePropertyHelper.Accessor() { >> 56: @Override >> 57: public boolean equalsAfterChangeStyleValue(StyleableProperty property, Object value) { > > minor: would it be slightly more organized to call a private instance method of the property class from each accessor? > > I think the code is ok, it's just adds so much nearly identical code that bothers me, though I can't figure out a way to avoid the `Accessor` pattern here, package protected methods would not work, would they? I've factored out the implementation into a private `equalsEndValue(Object)` method on each property class. The accessor pattern is unfortunate here, but the only alternative would be to add the method as public API to the `StyleableProperty` interface, and that's probably not something that we should do just to fix a bug. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2038#discussion_r2695778829 From angorya at openjdk.org Thu Jan 15 20:09:42 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 20:09:42 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 20:07:43 GMT, Michael Strau? wrote: >> In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: >> >> >> public class InterruptedTransitionBug extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> var root = new StackPane(new Button("My Button")); >> var scene = new Scene(root, 600, 200); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> .button { >> transition: -fx-scale-x 2s; >> } >> >> @media (width > 300px) { >> .button { >> -fx-scale-x: 2; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> ### Problem >> First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: >> 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. >> 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. >> 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. >> >> However, when transitions come into play, this mechanism can break: >> 1. In our example, the `Button` starts with a style map that contains two properties: >> * `transition: -fx-scale-x 2s` >> * `-fx-scale-x: 2` >> 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: >> * `transition: -fx-scale-x 2s` >> 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: >> * `-fx-scale-x` is reset to `1` >> * `transition` is reset to `null` >> >> This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. >> >> ### Solution >> Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that ar... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > private equalsEndValue() implementation Thank you, it's better to keep related logic closer together. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2038#pullrequestreview-3667375162 From mstrauss at openjdk.org Thu Jan 15 20:52:54 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 15 Jan 2026 20:52:54 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> Message-ID: <8AJAMdDuJ03snOo-6TrBhQSNwJ8TEk-OTX9ut5Jh6C0=.516cb3d0-30bd-4490-9a39-bc846c8d2210@github.com> On Thu, 15 Jan 2026 19:24:53 GMT, John Hendrikx wrote: > Are you referring to media queries for the window size when you say that sizing can influence styling? The others can be resolved similar to how `ScrollPane` does this (see below). Yes, but also in a more general sense. Applications might also manually add or remove style classes depending on the size of controls. > I would say that there's also two passes in FX, although less obvious. The first pass is basically the calling of the compute methods. These cascade down all the way down to the leaf level as each compute will call child compute methods (but can use cached results) before any layout methods are called (apart from the root one). I'm not sure what that pass should be called, but it does sound a lot like what WPF is doing. Only after this does the layout pass cascade down again via the layout calls. That's true, but it's also less powerful than a dedicated two-pass approach. The main difference is that WPF/Android communicate down constraints to children during this first pass, asking: "given my available size, how large would you like to be?" The compute methods of JavaFX don't communicate any information from parents to their children, which is why children can't change their answer depending on the constraints imposed by their parents. > `ScrollPane` handles that in one pass. Basically it computes the size of the children, and if it determines there is need of a scroll bar, it does those calculations again (which can result in the appearance of the 2nd scrollbar, and the calculations are repeated one more time; this is quite visible in `ScrollPaneSkin`). In effect, it solves this problem internally without waiting for another layout pass, as compute methods can be called as often as desired. > I think doing a loop of layout passes up to a limit is fine, although I'm not sure if CSS needs to take part in that. One should not be changing styles during layout, that's a pre-layout concern (which is before CSS runs) and not something to do in the `compute` chain of methods nor the `layoutChildren` methods. Let's assume a control where the number of children depend on its size. Maybe it arranges a set of nodes that it was provided with in some way, and fills the remaining "unused" slots in its layout with placeholder nodes. This implies that the control only knows how many placeholder nodes it needs after it was laid out. Adding those nodes after the layout pass is done means that they now don't have CSS styling. I think a case like this is already accounted for in the existing layout system, but solving this correctly in an iterative system probably means that CSS needs to be part of the loop. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3756800084 From angorya at openjdk.org Thu Jan 15 20:54:01 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 20:54:01 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements Message-ID: The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. Improvements include: - syncing the toolbar with current character attributes - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) - paragraph format dialog, with the associated toolbar button and the main menu item Screenshot 2026-01-15 at 12 01 44 Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): - type something - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold - type something and confirm that inserted text is bold the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. ------------- Commit messages: - Merge branch 'master' into 8373936.editor - Merge branch 'master' into 8373936.editor - whitespace - whitespace - Merge branch '8374035.insert.styles' into 8373936.editor - 2026 - Merge branch 'master' into 8374035.insert.styles - Merge branch '8374347.paragraph.direction' into 8373936.editor - 2026 - Merge branch 'master' into 8374347.paragraph.direction - ... and 24 more: https://git.openjdk.org/jfx/compare/66df38df...34dfb0f8 Changes: https://git.openjdk.org/jfx/pull/2026/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373936 Stats: 1223 lines in 12 files changed: 797 ins; 308 del; 118 mod Patch: https://git.openjdk.org/jfx/pull/2026.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2026/head:pull/2026 PR: https://git.openjdk.org/jfx/pull/2026 From fkirmaier at openjdk.org Thu Jan 15 21:02:04 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 15 Jan 2026 21:02:04 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v3] In-Reply-To: References: Message-ID: > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8375444 Removed unnecessary newline ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2040/files - new: https://git.openjdk.org/jfx/pull/2040/files/1701bdcb..4f7416ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2040.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2040/head:pull/2040 PR: https://git.openjdk.org/jfx/pull/2040 From angorya at openjdk.org Thu Jan 15 21:02:05 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 21:02:05 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 20:57:55 GMT, Florian Kirmaier wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8375444 > Removed unnecessary newline Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2040#pullrequestreview-3667549344 From angorya at openjdk.org Thu Jan 15 21:58:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 21:58:28 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: <9O0PjqkxndeuLXsrXz9WIYlk3I32MgaEuhQ6mRMbGbU=.e865939f-3ad1-4e23-98af-ac8f382e9f2f@github.com> References: <9O0PjqkxndeuLXsrXz9WIYlk3I32MgaEuhQ6mRMbGbU=.e865939f-3ad1-4e23-98af-ac8f382e9f2f@github.com> Message-ID: On Thu, 15 Jan 2026 19:45:21 GMT, Christopher Schnick wrote: >> I am confused. Are you commenting on the right part of the diff? I don't see anything related to strings in this part > > Ah, I think I know what you mean now. > > Since this is about the handling of generics, the original catch block should never be reached in my understanding. The generic T type is erased, meaning this method should always return the value, regardless of whether the type matches or not. > > If you do assign the return value of this method to a String, and the returned value is not of type string, it will always throw a ClassCastException. But that should also happen for the old method with the catch block as well. The exception happens outside the method, that is the important part my point this is not an equivalent change, because it changes the behavior. Before the change, a null will be returned, after this change - a non-null value of some other class. we don't want to change the scope of this PR, right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2696094513 From duke at openjdk.org Thu Jan 15 22:21:07 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 22:21:07 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v6] In-Reply-To: References: Message-ID: <6QawQWHnXbs_ZQLTOp2drAux4ddp1zTcfItlqArXejU=.dc846184-8fa9-4256-ac6e-a68558b35945@github.com> > This PR replaces various catch blocks for NPEs by proper null checks. It looks like a lot but most of the binding changes are just variants of the same approach. The test cases have been adapted to not check for NPEs anymore. > > The PrismFontFactory change to a RuntimeException was made because I don't see how the try block can throw an NPE. Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Add test clarifying generics handling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2032/files - new: https://git.openjdk.org/jfx/pull/2032/files/695c4da7..6d683d3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2032&range=04-05 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2032.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2032/head:pull/2032 PR: https://git.openjdk.org/jfx/pull/2032 From duke at openjdk.org Thu Jan 15 22:30:30 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 15 Jan 2026 22:30:30 GMT Subject: RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5] In-Reply-To: References: <9O0PjqkxndeuLXsrXz9WIYlk3I32MgaEuhQ6mRMbGbU=.e865939f-3ad1-4e23-98af-ac8f382e9f2f@github.com> Message-ID: On Thu, 15 Jan 2026 21:54:40 GMT, Andy Goryachev wrote: >> Ah, I think I know what you mean now. >> >> Since this is about the handling of generics, the original catch block should never be reached in my understanding. The generic T type is erased, meaning this method should always return the value, regardless of whether the type matches or not. >> >> If you do assign the return value of this method to a String, and the returned value is not of type string, it will always throw a ClassCastException. But that should also happen for the old method with the catch block as well. The exception happens outside the method, that is the important part > > my point this is not an equivalent change, because it changes the behavior. Before the change, a null will be returned, after this change - a non-null value of some other class. > > we don't want to change the scope of this PR, right? I added a test that should clarify the handling for mismatched types. The test passes both in the old and new implementation to show that the behaviour is the same and in both cases, null is never returned on mismatched types ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2696187250 From jhendrikx at openjdk.org Thu Jan 15 22:41:05 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 15 Jan 2026 22:41:05 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: <8AJAMdDuJ03snOo-6TrBhQSNwJ8TEk-OTX9ut5Jh6C0=.516cb3d0-30bd-4490-9a39-bc846c8d2210@github.com> References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> <8AJAMdDuJ03snOo-6TrBhQSNwJ8TEk-OTX9ut5Jh6C0=.516cb3d0-30bd-4490-9a39-bc846c8d2210@github.com> Message-ID: On Thu, 15 Jan 2026 20:48:57 GMT, Michael Strau? wrote: > > Are you referring to media queries for the window size when you say that sizing can influence styling? The others can be resolved similar to how `ScrollPane` does this (see below). > > Yes, but also in a more general sense. Applications might also manually add or remove style classes depending on the size of controls. True, and that's fine, but I think we need to warn if they do that during layout. That's just not the right time, as layouts are very restricted in what you should be doing. Most users never write a `layoutChildren` method and most aren't crazy enough to do these things in `compute` methods. They just need to be aware of things like pre/post layout listeners, and we need to ensure that user code is not called during layout (see below for cells...) > That's true, but it's also less powerful than a dedicated two-pass approach. The main difference is that WPF/Android communicate down constraints to children during this first pass, asking: "given my available size, how large would you like to be?" The compute methods of JavaFX don't communicate any information from parents to their children, which is why children can't change their answer depending on the constraints imposed by their parents. Yeah, FX has a limited variant of this with Content Bias. It can ask "If I give you 400 pixels of width, how much height do you want?" > > `ScrollPane` handles that in one pass. Basically it computes the size of the children, and if it determines there is need of a scroll bar, it does those calculations again (which can result in the appearance of the 2nd scrollbar, and the calculations are repeated one more time; this is quite visible in `ScrollPaneSkin`). In effect, it solves this problem internally without waiting for another layout pass, as compute methods can be called as often as desired. > > > I think doing a loop of layout passes up to a limit is fine, although I'm not sure if CSS needs to take part in that. One should not be changing styles during layout, that's a pre-layout concern (which is before CSS runs) and not something to do in the `compute` chain of methods nor the `layoutChildren` methods. > > Let's assume a control where the number of children depend on its size. Maybe it arranges a set of nodes that it was provided with in some way, and fills the remaining "unused" slots in its layout with placeholder nodes. This implies that the control only knows how many placeholder nodes it needs after it was laid out. Adding those nodes after the layout pass is done means that they now don't have CSS styling. I think a case like this is already accounted for in the existing layout system, but solving this correctly in an iterative system probably means that CSS needs to be part of the loop. Although I think I see why CSS needs to be added to the loop (and more), I still think that you should refrain from adding/removing children during layout, especially if they are cells. This still best handled in a pre-layout listener because if there is no follow-up loop, you will see CSS flicker (white background). Even in a looped system this can then occur when loops are exhausted. The View classes are good examples of dynamic controls that need to have more or less children depending on their size. They should be initializing these children (including calling `Cell#updateItem`) as part of a pre-layout listener. This allows: - Flicker free adding of children (CSS runs still, no need to rely on a next loop) - User code doing whatever they want in `updateItem` which is not the case if that method is called during the layout phase (there are bugs currently where sometimes `updateItem` is called during layout.. very bad, as users are unaware that this is the case) If it turns out there weren't enough (invisible) cells to fill the entire view port, then the View class can request another layout pass, which can be looped immediately (and should include calling the pre-layout listeners again). So I think you are right here that we should include CSS in the loop so newly added children in a 2nd loop also get the correct styles (hopefully it's cheap if not much changed). So I think it perhaps could work like this: 1. Pulse starts 2. Pre-layout listeners called - View controls add/remove children, call `updateItem` based on their current size - `updateItem` can do whatever it wants, including modifying styles, adding/removing children, user code need not worry about layout semantics 3. CSS pass LAYOUT STARTS -- refrain from doing "more" work besides positioning/sizing 4. Sizes get computed (by `resizeRootToPreferredSize`) down to leafs 5. Layout methods are called (according to dirty status) down to leafs LAYOUT ENDS 6. Either during layout or in a post-layout listener, the View class discovers it did not have enough cells, it asks for a new layout 7. After post layout listeners have run, check if another layout is needed immediately, go to step 2 (unless limit exceeded) 8. Pulse ends In this way we can prevent unnecessary layouts, and also prevent doing dangerous things during layout. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3757227855 From angorya at openjdk.org Thu Jan 15 23:15:12 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 23:15:12 GMT Subject: RFR: 8370902: RichTextArea: migrate to new text APIs Message-ID: Updates the `RichTextArea` code to use the new text layout APIs delivered in https://bugs.openjdk.org/browse/JDK-8341670 Also: - updates the "demo" model in the `RichTextAreaDemoApp` to show underline/strikethrough in the presence of `TextFlow` borders ------------- Commit messages: - 2026 - Merge branch 'master' into 8370902.new.api - Merge branch 'master' into 8370902.new.api - new api Changes: https://git.openjdk.org/jfx/pull/2012/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2012&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370902 Stats: 66 lines in 5 files changed: 14 ins; 26 del; 26 mod Patch: https://git.openjdk.org/jfx/pull/2012.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2012/head:pull/2012 PR: https://git.openjdk.org/jfx/pull/2012 From angorya at openjdk.org Thu Jan 15 23:15:24 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 15 Jan 2026 23:15:24 GMT Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v13] 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 18 additional commits since the last revision: - Merge branch 'master' into 8353599.menu.factory - 2026 - Merge branch '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 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 - ... and 8 more: https://git.openjdk.org/jfx/compare/c0c73ebf...9228913b ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1773/files - new: https://git.openjdk.org/jfx/pull/1773/files/85a2926a..9228913b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1773&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1773&range=11-12 Stats: 6134 lines in 100 files changed: 4918 ins; 482 del; 734 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 lbourges at openjdk.org Fri Jan 16 07:16:07 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 16 Jan 2026 07:16:07 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 13:57:47 GMT, Kevin Rushforth wrote: >> Will fix compilation failure asap (missing module access) > > @bourgesl Can you create an automated test for this, perhaps derived from the Java2D test in [JDK-8341381](https://bugs.openjdk.org/browse/JDK-8341381)? > > Reviewers: @kevinrushforth @lukostyra @kevinrushforth of course I could but I need time to convert this 2d test to jfx gameloop... I wonder if it is worth the price... ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3758501999 From hmeda at openjdk.org Fri Jan 16 08:26:50 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 16 Jan 2026 08:26:50 GMT Subject: RFR: 8368572: Update WebKit to 623.1 Message-ID: This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. ------------- Commit messages: - change file permissions - whitespace correction - Update webkit to v623.1 Changes: https://git.openjdk.org/jfx/pull/2042/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8368572 Stats: 505661 lines in 8991 files changed: 253929 ins; 188948 del; 62784 mod Patch: https://git.openjdk.org/jfx/pull/2042.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2042/head:pull/2042 PR: https://git.openjdk.org/jfx/pull/2042 From kcr at openjdk.org Fri Jan 16 13:17:25 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 13:17:25 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. Reviewers: @kevinrushforth @jaybhaskar @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/2042#issuecomment-3759976158 From kcr at openjdk.org Fri Jan 16 13:52:55 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 13:52:55 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: <_L5vjGf3jZDX5TloPUTfETl-ylU9G_3W-Rj_TUTB0T0=.cef06a9e-cc3e-41f4-97d8-07b5462eda2b@github.com> On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/2037#pullrequestreview-3670959676 From kcr at openjdk.org Fri Jan 16 15:34:51 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 15:34:51 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:18:37 GMT, Laurent Bourg?s wrote: >> merged changes with Java2D bug JDK-8341381 (trivial port on src only) >> >> See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > made Helpers.ulp public to fix compilation How much time would it take? As an alternative, do you have a manual test program that will show the error? Given that this is a port of a fix that already went into Java2D, a manual test program might be sufficient (and we can file a follow-up test bug to consider an automated test later). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3760588770 From angorya at openjdk.org Fri Jan 16 15:34:52 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 15:34:52 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 15:27:18 GMT, Kevin Rushforth wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> made Helpers.ulp public to fix compilation > > How much time would it take? As an alternative, do you have a manual test program that will show the error? Given that this is a port of a fix that already went into Java2D, a manual test program might be sufficient (and we can file a follow-up test bug to consider an automated test later). I am trying to come up with a reproducer, @kevinrushforth @bourgesl ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3760601113 From lkostyra at openjdk.org Fri Jan 16 15:39:27 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 16 Jan 2026 15:39:27 GMT Subject: RFR: 8210547: [Linux] Uncontrolled framerate [v3] In-Reply-To: References: Message-ID: On Tue, 30 Dec 2025 23:01:55 GMT, notzed wrote: >> As discussed on the mailing list. >> >> OpenGL requires an explicit glFinish() to synchronise with the video refresh. The current usage is incorrect and against the specification. This patch calls glFinish() after all windows have been drawn following a pulse. > > notzed has updated the pull request incrementally with one additional commit since the last revision: > > Merge part of #1929, call glXSwapIntervalEXT in preference to glXSwapIntervalSGI if available. Change looks good to me and it now works as expected on my old Intel laptop (framerate is properly capped without `-Dquantum.multithreaded=false`). I have one more comment suggestion before approving this while I run some additional tests in the meantime. modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 193: > 191: boolean presented = present(); > 192: > 193: if (vsync) I would add a comment here describing the reason for this addition so we have it for future reference - something along the lines of glFinish needing to be called only on the last presented Stage in order to properly synchronize them all to VSync. ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1981#pullrequestreview-3671299072 PR Review Comment: https://git.openjdk.org/jfx/pull/1981#discussion_r2698860645 From sykora at openjdk.org Fri Jan 16 16:33:57 2026 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 16 Jan 2026 16:33:57 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: <69WcRAbgecOsKMlm3-UwmnI1qw-Cat1fugKXLh28C2E=.34c47818-9324-461c-8eac-56e0adb6c6b7@github.com> On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. The builds succeeded on all platforms. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/2042#pullrequestreview-3671716082 From angorya at openjdk.org Fri Jan 16 17:38:55 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 17:38:55 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors [v2] In-Reply-To: References: Message-ID: <_OGIFO742hwuDbbqi4wtliwBmeR86yLqm074Jz-eenY=.7005fea7-ee5c-4989-bd68-355272204a13@github.com> On Thu, 15 Jan 2026 11:18:37 GMT, Laurent Bourg?s wrote: >> merged changes with Java2D bug JDK-8341381 (trivial port on src only) >> >> See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > made Helpers.ulp public to fix compilation I came up with what I think is an equivalent of the Main.java in https://bugs.openjdk.org/browse/JDK-8341381 I noticed that the shapes do not correspond to the GIF in the ticket - the curves in the bug form a text outline, whereas the GIF shows something else. Not sure if important. What's important is that I cannot reproduce the issue with the latest master branch. Please use the latest monkey tester from https://github.com/andy-goryachev-oracle/MonkeyTest select the Shape page and set the properties according to the screenshot: Screenshot 2026-01-16 at 09 27 59 Here is the reproducer part of the code: https://github.com/andy-goryachev-oracle/MonkeyTest/blob/b19d640533b89068644426dcf6aa7f137b4d4334/src/com/oracle/tools/fx/monkey/pages/ShapePage.java#L213 What am I doing wrong, @bourgesl ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3761097089 From duke at openjdk.org Fri Jan 16 17:49:12 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 17:49:12 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment So now the necessary reviews are there, I can just integrate this then? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3761107749 From angorya at openjdk.org Fri Jan 16 17:49:12 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 17:49:12 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment yes, just add `/integrate` comment ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3761116971 From kcr at openjdk.org Fri Jan 16 17:49:13 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 17:49:13 GMT Subject: RFR: 8375227: Silent OOBE in NGGroup::renderContent [v3] In-Reply-To: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> References: <1dPS_GjJpehXMym7qeXUica4mv6fUHYs4dXtmeb4n-E=.b97b8804-9690-4636-85c9-e90470badf6d@github.com> Message-ID: On Thu, 15 Jan 2026 15:37:58 GMT, Christopher Schnick wrote: >> This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. >> >> The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. >> >> The fix should retain the exact original workings of the method while avoiding the exception. > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Yes, you may proceed. I recommend filing a follow-up issue (P4 priority) to consider removing the try/catch as discussed above. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2037#issuecomment-3761118467 From duke at openjdk.org Fri Jan 16 17:49:14 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 17:49:14 GMT Subject: Integrated: 8375227: Silent OOBE in NGGroup::renderContent In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 21:38:19 GMT, Christopher Schnick wrote: > This is a very basic solution to the OOBE described in the issue. While it would definitely be better to figure out the root cause, understanding the NGNode implementation is above my knowledge level atm. > > The code has been like that for 10 years and no one complained, so I am not sure whether this is a deeper issue or just a small oversight when handling all possible cases. > > The fix should retain the exact original workings of the method while avoiding the exception. This pull request has now been integrated. Changeset: 40c0292b Author: Christopher Schnick Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/40c0292bad60e9ecca16725f2f61dca032ceff62 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8375227: Silent OOBE in NGGroup::renderContent Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/2037 From jvos at openjdk.org Fri Jan 16 17:50:51 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 16 Jan 2026 17:50:51 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:34:15 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=48169 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=48168 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx25u/pull/43#pullrequestreview-3672022704 From duke at openjdk.org Fri Jan 16 18:22:35 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 18:22:35 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup Message-ID: This should improve the code quality of the class while preserving its original workings ------------- Commit messages: - Clean up NGGroup Changes: https://git.openjdk.org/jfx/pull/2043/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375561 Stats: 41 lines in 1 file changed: 0 ins; 25 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/2043.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2043/head:pull/2043 PR: https://git.openjdk.org/jfx/pull/2043 From lbourges at openjdk.org Fri Jan 16 18:55:06 2026 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 16 Jan 2026 18:55:06 GMT Subject: RFR: 8370729: Precision errors in Marlin 0.9.4.6 can cause rendering errors [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 11:18:37 GMT, Laurent Bourg?s wrote: >> merged changes with Java2D bug JDK-8341381 (trivial port on src only) >> >> See https://github.com/openjdk/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > made Helpers.ulp public to fix compilation The tricky part in this test consists in falling in magic cubic values depending on scale & viewport... that should be reproduced as in the gif case. I will try capturing a failing cubic value in marlin2d to draw it exactly with javafx (same exact coefficients) ... It will take me spare time so this PR can be back to draft. > I came up with what I think is an equivalent of the Main.java in https://bugs.openjdk.org/browse/JDK-8341381 > > I noticed that the shapes do not correspond to the GIF in the ticket - the curves in the bug form a text outline, whereas the GIF shows something else. Not sure if important. > > What's important is that I cannot reproduce the issue with the latest master branch. > > Please use the latest monkey tester from https://github.com/andy-goryachev-oracle/MonkeyTest > > select the Shape page and set the properties according to the screenshot: Screenshot 2026-01-16 at 09 27 59 > > Here is the reproducer part of the code: https://github.com/andy-goryachev-oracle/MonkeyTest/blob/b19d640533b89068644426dcf6aa7f137b4d4334/src/com/oracle/tools/fx/monkey/pages/ShapePage.java#L213 > > What am I doing wrong, @bourgesl ? I will try reproducing this weird scale or extract transformed values to make bad cubics ------------- PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3761352904 PR Comment: https://git.openjdk.org/jfx/pull/2039#issuecomment-3761359615 From kcr at openjdk.org Fri Jan 16 19:15:10 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 19:15:10 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 18:14:35 GMT, Christopher Schnick wrote: > This should improve the code quality of the class while preserving its original workings This goes beyond addressing the removal of the try/catch. I'm not sure whether the value of the additional cleanup is worth the effort to review (and test) it. I highlighted one of the removed null checks where we need to see that there won't be any behavioral change. At a minimum, please explain all of the non-obvious changes in the PR description or in a comment. Specifically: 1. Are you confident that the try/catch is no longer needed. I suspect that Michael was right and that it isn't, but I'd like to see at least a few words of explanation from you. 2. For the removed null checks, can you show that the object in question can never be null? modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 221: > 219: List orderedChildren = getOrderedChildren(); > 220: for (NGNode orderedChild : orderedChildren) { > 221: orderedChild.renderForcedContent(gOptional); If `getOrderedChildren()` can ever return null, then the null check is needed, so I can't tell without digging a little whether this is a safe fix. ------------- PR Review: https://git.openjdk.org/jfx/pull/2043#pullrequestreview-3672286753 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2699635148 From duke at openjdk.org Fri Jan 16 19:15:12 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 19:15:12 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 18:58:45 GMT, Kevin Rushforth wrote: >> This should improve the code quality of the class while preserving its original workings > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 221: > >> 219: List orderedChildren = getOrderedChildren(); >> 220: for (NGNode orderedChild : orderedChildren) { >> 221: orderedChild.renderForcedContent(gOptional); > > If `getOrderedChildren()` can ever return null, then the null check is needed, so I can't tell without digging a little whether this is a safe fix. Should I add the explanations in the PR or the JBS issue? Andy also asked for a summary in the JBS issue, so ideally I would combine that ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2699670793 From andy.goryachev at oracle.com Fri Jan 16 19:31:59 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 16 Jan 2026 19:31:59 +0000 Subject: DataFormat threading and API issues Message-ID: Dear JavaFX developers: I wanted to as your opinion on this: Problem There seems to be several issues with DataFormat API and implementation discovered during a Clipboard-related code review: 1. static DataFormat::lookupMimeType(String) is not thread safe: while iterating over previously registered entries in the DATA_FORMAT_LIST another thread might create a new instance (DataFormat L227) 2. public DataFormat(String...) constructor might throw an IllegalArgumentException if one of the given mime types is already assigned to another DataFormat. The origin of this requirement is unclear, but one possible issue I can see is if the application has two libraries that both attempt to create a DataFormat for let's say "text/css". Then, depending on the timing or the exact code path, an exception will be thrown for which the library(-ies) might not be prepared. The constructor is also not thread safe. 3. To avoid a situation mentioned in bullet 2, a developer would is typically call lookupMimeType() to obtain an already registered instance, followed by a constructor call if such an instance has not been found. An example of such code can be seen in webkit/UIClientImpl:299 - but even then, despite that two-step process being synchronized, the code might still fail if some other library or the application attempts to create a new instance of DataFormat, since the constructor itself is not synchronized. 4. DataFormat(new String[] { null }) is allowed but makes no sense! Why do we need to have the registry of previously created instances? Unclear. My theory is that the DataFormat allows to have multiple mime-types (ids) - example being DataFormat.FILES = new DataFormat("application/x-java-file-list", "java.file-list"); - and the registry was added to prevent creation of a DataFormat with just one id for some reason. What should be done? * find out why we need this registry in the first place i.e. what could happen if we have multiple DataFormat instances with overlapping ids. * if the registry is needed add a new factory method, something like DataFormat::of(String ...) which is properly synchronized. This method will be called by the constructor to retain the backward compatibility. * deprecate (possibly for removal) DataFormat::lookupMimeType(String), or keep it but have it properly synchronized Dangers 1. adding synchronization might lead to deadlocks if the application or library has existing code synchronized around some other object and not DataFormat.class. 2. removing the public constructor is a very visible, breaking change Alternatives We could possibly prevent the application code creating DataFormats with multiple ids by * creating a public DataFormat(String) constructor * allowing multiple instances with the same id by removing the registry or using the registry only for DataFormats with multiple ids Draft PR: https://github.com/openjdk/jfx/pull/2006 Thanks, -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Fri Jan 16 20:47:21 2026 From: mfox at openjdk.org (Martin Fox) Date: Fri, 16 Jan 2026 20:47:21 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v71] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 21:00:47 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 85 commits: > > - Merge branch 'master' into 8354943 > > # Conflicts: > # tests/system/src/test/java/test/util/Util.java > - Merge branch 'master' into 8354943 > - Remote assumeTrue for JDK-8364547 > - Merge branch 'master' into 8354943 > - 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 > - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205 I'm glad to see this code cleaned up and the new tests added. It would be great if this could get integrated into 27 soon so it gets more real-world testing. I've left comments in the code related to some minor issues, none of them blocking. modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 134: > 132: minimizeImpl(ptr, minimize); > 133: > 134: if (!isVisible()) { This check is new and only happens when minimizing, not maximizing. Under what conditions does this occur? modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 190: > 188: > 189: window_size.setOnChange([this](const Size& size) { > 190: notify_window_resize(is_maximized() There is a very minor bug here that's also present in the master branch. If the size of a window is changed when it's iconified it can't be un-iconified. This notification tells the Java Window that it has been restored even though it's still iconified which confuses the bookkeeping. This is an old bug so I would be fine if we just enter a bug report and push the fix off to another PR. Unfortunately there's no way to write an automated test. That would require adding a call to query the OS for the window's state so we can compare it with the state the Java Window is tracking. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 822: > 820: > 821: void WindowContext::update_initial_state() { > 822: GdkWindowState state = gdk_window_get_state(gdk_window); This handles the case where set_maximized, set_minimized, or enter_fullscreen are called after the peer is created but before it's mapped. Oh no! This is an ugly part of the code. For one, when these state flags are set on a Java Window before it is shown the code just stashes them away. When the Window is shown the code applies them in a fixed order: fullscreen, iconified, maximized. So if iconified and maximized are both set the window should end up maximized. For two, the documentation and code treat iconified/maximized/restored as a trio of mutually exclusive states which are entirely separate from fullscreen (which overrides them all). This is probably a relic of the days when fullscreen was implemented using an entirely separate window. In practice the platform code doesn't honor this separation and if you mix fullscreen with iconified or maximized you'll get different results on different platforms (and the Java state is likely to get confused). The end result is a bit of a mess. The good news is this leads to the sort of spec violations and bugs that no one notices. TL;DR - I think the correct order to apply these flags is iconified, maximized, and then fullscreen. This is different than the order the core code uses but, again, as far as it's concerned fullscreen overrides maximized and iconified. To honor that it should be applied last. modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1059: > 1057: > 1058: void WindowContext::notify_current_sizes() { > 1059: notify_window_resize(is_maximized() This should also be checking for is_iconified. Again, unlikely to be introducing a new bug so this fix can be pushed to a separate PR. ------------- PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3672159390 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2699534109 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2699581987 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2699899249 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2699592229 From duke at openjdk.org Fri Jan 16 20:52:07 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 20:52:07 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 19:11:54 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 221: >> >>> 219: List orderedChildren = getOrderedChildren(); >>> 220: for (NGNode orderedChild : orderedChildren) { >>> 221: orderedChild.renderForcedContent(gOptional); >> >> If `getOrderedChildren()` can ever return null, then the null check is needed, so I can't tell without digging a little whether this is a safe fix. > > Should I add the explanations in the PR or the JBS issue? Andy also asked for a summary in the JBS issue, so ideally I would combine that Added a detailed summary for the changes in the JBS issue ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2699922383 From jhendrikx at openjdk.org Fri Jan 16 22:12:52 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jan 2026 22:12:52 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 18:14:35 GMT, Christopher Schnick wrote: > This should improve the code quality of the class while preserving its original workings modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 204: > 202: * @param blendMode cannot be null > 203: */ > 204: public void setBlendMode(Blend.Mode blendMode) { This method looks unused, may as well remove if we're cleaning up stuff. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 268: > 266: if (child != null) { > 267: child.render(g); > 268: } That's some pretty poor code to begin with. If there is any worry at all that this can be called from multiple threads, then `synchronized` should be used. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 287: > 285: } while (bot == null || !idValid); > 286: > 287: bot.unref(); This `null` check could be important if a `Group` is empty. Please verify. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 451: > 449: NGNode child; > 450: List orderedChildren = getOrderedChildren(); > 451: for (NGNode orderedChild : orderedChildren) { You may want to stick with the normal `for` loops as they don't require allocating an iterator object. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700114515 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700119175 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700124885 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700126762 From jhendrikx at openjdk.org Fri Jan 16 22:12:53 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 16 Jan 2026 22:12:53 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:46:25 GMT, Christopher Schnick wrote: >> Should I add the explanations in the PR or the JBS issue? Andy also asked for a summary in the JBS issue, so ideally I would combine that > > Added a detailed summary for the changes in the JBS issue Looks okay, it can't ever return `null`; FX is full of unnecessary `null` checks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700116564 From duke at openjdk.org Fri Jan 16 22:25:29 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 22:25:29 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: > This should improve the code quality of the class while preserving its original workings Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: - Remove space - Use for loops again - Remove unused method ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2043/files - new: https://git.openjdk.org/jfx/pull/2043/files/d0814ea8..898af0f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=00-01 Stats: 24 lines in 1 file changed: 1 ins; 17 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/2043.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2043/head:pull/2043 PR: https://git.openjdk.org/jfx/pull/2043 From angorya at openjdk.org Fri Jan 16 22:25:35 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 22:25:35 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:22:57 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: > > - Remove space > - Use for loops again > - Remove unused method @crschnick : thanks for looking at the code and trying to make it better! I would say one thing: I would rather have us spend time on fixing real bugs rather than introduce unnecessary changes. A cleanup is good, but there is always a danger of introducing a regression, so we should probably undertake it only if a) it's a trivial and obvious change (like the unnecessary exceptions you did earlier) or b) the changes are a part of some greater redesign modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 231: > 229: return; > 230: } > 231: for (int i = 0; i < orderedChildren.size(); i++) { I don't know why we need to change for forEach loop, at the expense of extra memory allocation. the old code is perfectly fine. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 287: > 285: } while (bot == null || !idValid); > 286: > 287: bot.unref(); I am not sure of this, I'd suggest to revert. This is a kind of change that we should not be making: - it's very time consuming to code review - if developer of reviewers collectively made a mistake and missed a case, it causes regression. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 297: > 295: } > 296: List orderedChildren = getOrderedChildren(); > 297: int n = orderedChildren.size(); please remove extra space modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 301: > 299: return orderedChildren.get(0).hasOverlappingContents(); > 300: } > 301: return (n > 0); the change seems ok, but... why do you force me think? modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 452: > 450: List orderedChildren = getOrderedChildren(); > 451: for (NGNode orderedChild : orderedChildren) { > 452: child = orderedChild; completely unnecessary: you've added unnecessary memory allocation (and iterator). please revert. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 473: > 471: clone = clone.deriveWithConcatenation(getTransform()); > 472: List orderedChildren = getOrderedChildren(); > 473: for (final NGNode child : orderedChildren) { please revert, for the same reason (unnecessary, extra work for computer and people alike) ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2043#pullrequestreview-3672902406 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700110052 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700119001 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700121157 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700121926 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700125746 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700127034 From duke at openjdk.org Fri Jan 16 22:25:42 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 22:25:42 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:01:09 GMT, John Hendrikx wrote: >> Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove space >> - Use for loops again >> - Remove unused method > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 204: > >> 202: * @param blendMode cannot be null >> 203: */ >> 204: public void setBlendMode(Blend.Mode blendMode) { > > This method looks unused, may as well remove if we're cleaning up stuff. Good catch, removed it > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 287: > >> 285: } while (bot == null || !idValid); >> 286: >> 287: bot.unref(); > > This `null` check could be important if a `Group` is empty. Please verify. It can't reach that part if the value is null. The preceding while loop will loop until it is not null > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 451: > >> 449: NGNode child; >> 450: List orderedChildren = getOrderedChildren(); >> 451: for (NGNode orderedChild : orderedChildren) { > > You may want to stick with the normal `for` loops as they don't require allocating an iterator object. Is that nowadays still not optimized internally to some degree? Since for each loops are so common now, I thought that the compiler would perform good enough optimizations. I chose for each loops here because the original issue was caused by the indicies in the for loop ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700144429 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700142140 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700138945 From angorya at openjdk.org Fri Jan 16 22:25:43 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 22:25:43 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:15:19 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 204: >> >>> 202: * @param blendMode cannot be null >>> 203: */ >>> 204: public void setBlendMode(Blend.Mode blendMode) { >> >> This method looks unused, may as well remove if we're cleaning up stuff. > > Good catch, removed it Are you sure? What about Android/iOS/other platform supported by Gluon? @johanvos >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 451: >> >>> 449: NGNode child; >>> 450: List orderedChildren = getOrderedChildren(); >>> 451: for (NGNode orderedChild : orderedChildren) { >> >> You may want to stick with the normal `for` loops as they don't require allocating an iterator object. > > Is that nowadays still not optimized internally to some degree? Since for each loops are so common now, I thought that the compiler would perform good enough optimizations. > > I chose for each loops here because the original issue was caused by the indicies in the for loop Optimization: I don't know. Maybe, maybe not. I suspect the contract is to create the iterator. My main point - it is a completely unnecessary change, a change for the sake of change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700154304 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700163429 From angorya at openjdk.org Fri Jan 16 22:25:45 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 22:25:45 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: <4phts9CLrScP2Ba13ujSXXlTCEn-T-sbcovygPBzEK8=.29cf94fb-e659-4656-bb10-fae988da413a@github.com> On Fri, 16 Jan 2026 20:46:25 GMT, Christopher Schnick wrote: >> Should I add the explanations in the PR or the JBS issue? Andy also asked for a summary in the JBS issue, so ideally I would combine that > > Added a detailed summary for the changes in the JBS issue looks like `getOrderedChildren()` never returns null ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700111433 From duke at openjdk.org Fri Jan 16 22:25:47 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 22:25:47 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: <5bm8V6HwZjX10XscTtZjHCJnRAdESTV8wkk6nyIBAbQ=.92073125-a7cb-47c5-be09-fe19b864bbc5@github.com> On Fri, 16 Jan 2026 21:58:49 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove space >> - Use for loops again >> - Remove unused method > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 231: > >> 229: return; >> 230: } >> 231: for (int i = 0; i < orderedChildren.size(); i++) { > > I don't know why we need to change for forEach loop, at the expense of extra memory allocation. the old code is perfectly fine. Reverted > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 287: > >> 285: } while (bot == null || !idValid); >> 286: >> 287: bot.unref(); > > I am not sure of this, I'd suggest to revert. > > This is a kind of change that we should not be making: > - it's very time consuming to code review > - if developer of reviewers collectively made a mistake and missed a case, it causes regression. I agree, but it's not that complicated. There is a while loop that precedes this which will not exit until bot != null and it does not contain break statements. > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 297: > >> 295: } >> 296: List orderedChildren = getOrderedChildren(); >> 297: int n = orderedChildren.size(); > > please remove extra space Fixed > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 452: > >> 450: List orderedChildren = getOrderedChildren(); >> 451: for (NGNode orderedChild : orderedChildren) { >> 452: child = orderedChild; > > completely unnecessary: you've added unnecessary memory allocation (and iterator). > > please revert. Reverted > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 473: > >> 471: clone = clone.deriveWithConcatenation(getTransform()); >> 472: List orderedChildren = getOrderedChildren(); >> 473: for (final NGNode child : orderedChildren) { > > please revert, for the same reason (unnecessary, extra work for computer and people alike) Reverted ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700166541 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700169240 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700165377 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700164594 PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700164268 From angorya at openjdk.org Fri Jan 16 22:32:59 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 22:32:59 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:25:29 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: > > - Remove space > - Use for loops again > - Remove unused method modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 265: > 263: child = null; > 264: } > 265: // minimal protection against concurrent update of the list. see, this is a worrisome comment - and perhaps the value of this PR would be much higher if you can demonstrate that the concurrency is not an issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700188133 From duke at openjdk.org Fri Jan 16 22:38:23 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 16 Jan 2026 22:38:23 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:17:49 GMT, Andy Goryachev wrote: >> Good catch, removed it > > Are you sure? What about Android/iOS/other platform supported by Gluon? @johanvos If there is a method in the internal codebase that is not used in the entire jfx repo, is it safe to delete? Or do you have to take other sources/repos into consideration? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700199876 From mstrauss at openjdk.org Fri Jan 16 22:47:40 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 16 Jan 2026 22:47:40 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: <2UOKOh50tqLGbCFP96yPZ9kTgZI1BVQO6QXd7GdoHCA=.84e373a1-358a-4db5-ab27-2122ad9c8df9@github.com> On Fri, 16 Jan 2026 22:20:44 GMT, Andy Goryachev wrote: >> Is that nowadays still not optimized internally to some degree? Since for each loops are so common now, I thought that the compiler would perform good enough optimizations. >> >> I chose for each loops here because the original issue was caused by the indicies in the for loop > > Optimization: I don't know. Maybe, maybe not. I suspect the contract is to create the iterator. > > My main point - it is a completely unnecessary change, a change for the sake of change. An enhanced for-loop is syntactic sugar for: Iterator it = list.iterator(); while (it.hasNext()) { E e = it.next(); ... } If you look at the bytecode, you'll see that there is an object allocation. However, if C2 can prove via escape analysis that the iterator doesn't escape, it can 1. inline the `ArrayList.iterator()` call into the calling method, which is just a `new ArrayList$Itr()` expression, 2. scalarize the object allocation into locals, effectively storing `ArrayList$Itr`'s fields in the stack frame. So yes, an enhanced for-loop can be optimized by the C2 compiler so that it doesn't allocate any memory. However, this is not a guarantee, and optimization may fail for a number of reasons: 1. The call site must be monomorphic, that means that the runtime profile of the call site only ever sees `ArrayList` here. If different concrete `List` classes are encountered at runtime, the call site becomes polymorphic or megamorphic and the method call can't be inlined. 2. The iterator can't be proven to not escape (stored somewhere, passed to a method, etc.) 3. The call-site method body is too large, so that inlining of `ArrayList.iterator()` doesn't happen. All in all, it seems likely that iterator optimization will happen here. For clarity of intent, I would still recommend an indexed for-loop if you want to make sure that no object allocations happen at runtime, and I would also think in this case you should not repeatedly call the `List.size()` method, but just call it once: for (int i = 0, max = list.size(); i < max; ++i) { // the intent here is obvious ... } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700229772 From mstrauss at openjdk.org Fri Jan 16 22:50:48 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 16 Jan 2026 22:50:48 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:29:35 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove space >> - Use for loops again >> - Remove unused method > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 265: > >> 263: child = null; >> 264: } >> 265: // minimal protection against concurrent update of the list. > > see, this is a worrisome comment - and perhaps the value of this PR would be much higher if you can demonstrate that the concurrency is not an issue. I think that bar is too high, how would you even begin to demonstrate that it _isn't_ an issue? This class iterates over the very same list in six different places, none of which are "protected" with a try-catch block. I would think that this fact should be enough to say that even if concurrent modification was an issue, it must be solved differently. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700241743 From angorya at openjdk.org Fri Jan 16 23:12:33 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 16 Jan 2026 23:12:33 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:47:54 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 265: >> >>> 263: child = null; >>> 264: } >>> 265: // minimal protection against concurrent update of the list. >> >> see, this is a worrisome comment - and perhaps the value of this PR would be much higher if you can demonstrate that the concurrency is not an issue. > > I think that bar is too high, how would you even begin to demonstrate that it _isn't_ an issue? This class iterates over the very same list in six different places, none of which are "protected" with a try-catch block. I would think that this fact should be enough to say that even if concurrent modification was an issue, it must be solved differently. assuming for a moment that there is a problem (I don't know), at a minimum one needs to check if multiple threads are accessing the list. the reason is that we might have created a regression: before - an exception was silently ignored after - an exception would bubble up and break something else this is more of an argument against frivolous changes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700294128 From kcr at openjdk.org Fri Jan 16 23:29:59 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 16 Jan 2026 23:29:59 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:34:52 GMT, Christopher Schnick wrote: > If there is a method in the internal codebase that is not used in the entire jfx repo, is it safe to delete? Yes, if it is an internal method. In some cases (not this one), methods are called from JNI via an upcall, but those should all be either documented or for WebKit, follow a standard naming pattern. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700316780 From duke at openjdk.org Sat Jan 17 04:26:56 2026 From: duke at openjdk.org (Christopher Schnick) Date: Sat, 17 Jan 2026 04:26:56 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: <2UOKOh50tqLGbCFP96yPZ9kTgZI1BVQO6QXd7GdoHCA=.84e373a1-358a-4db5-ab27-2122ad9c8df9@github.com> References: <2UOKOh50tqLGbCFP96yPZ9kTgZI1BVQO6QXd7GdoHCA=.84e373a1-358a-4db5-ab27-2122ad9c8df9@github.com> Message-ID: On Fri, 16 Jan 2026 22:44:27 GMT, Michael Strau? wrote: >> Optimization: I don't know. Maybe, maybe not. I suspect the contract is to create the iterator. >> >> My main point - it is a completely unnecessary change, a change for the sake of change. > > An enhanced for-loop is syntactic sugar for: > > Iterator it = list.iterator(); > while (it.hasNext()) { > E e = it.next(); > ... > } > > > If you look at the bytecode, you'll see that there is an object allocation. However, if C2 can prove via escape analysis that the iterator doesn't escape, it can > 1. inline the `ArrayList.iterator()` call into the calling method, which is just a `new ArrayList$Itr()` expression, > 2. scalarize the object allocation into locals, effectively storing `ArrayList$Itr`'s fields in the stack frame. > > So yes, an enhanced for-loop can be optimized by the C2 compiler so that it doesn't allocate any memory. However, this is not a guarantee, and optimization may fail for a number of reasons: > 1. The call site must be monomorphic, that means that the runtime profile of the call site only ever sees `ArrayList` here. If different concrete `List` classes are encountered at runtime, the call site becomes polymorphic or megamorphic and the method call can't be inlined. > 2. The iterator can't be proven to not escape (stored somewhere, passed to a method, etc.) > 3. The call-site method body is too large, so that inlining of `ArrayList.iterator()` doesn't happen. > > All in all, it seems likely that iterator optimization will happen here. For clarity of intent, I would still recommend an indexed for-loop if you want to make sure that no object allocations happen at runtime, and I would also think in this case you should not repeatedly call the `List.size()` method, but just call it once: > > for (int i = 0, max = list.size(); i < max; ++i) { // the intent here is obvious > ... > } Thanks for the detailed explanation. That makes me feel better about using for each loops when possible in my code. For this PR, I reverted the for loops to the original variant due to other feedback. The implementation to call the size() method only once looks interesting. However I have never seen that in an actual codebase. Probably because the overhead for a normal size() call is quite small and seeing such a loop would, as Andy would say it, require more thinking for anyone having to look at it. But I like it, maybe I can make use of that somewhere ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2700623710 From fthevenet at openjdk.org Sat Jan 17 11:42:54 2026 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Sat, 17 Jan 2026 11:42:54 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. Any chances that this will make it to JavaFX 26, since we've now entered RDP1? If not GA, what's the process to get it into the first 26 update? I'm familiar with the JDK backport process; does JavaFX uses a similar process? Thanks ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3763201023 From kcr at openjdk.org Sat Jan 17 15:25:58 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 17 Jan 2026 15:25:58 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: <_KqCkl3NzzGiSk5VTV6lcI8DJ56Pmb3gxM8u91E24Go=.f58c59b8-b7dc-43d7-a266-bcc61b4ed276@github.com> On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. This enhancement request seems better suited for JavaFX 27. We do use the same process as the JDK does for backporting. See [this message](https://mail.openjdk.org/pipermail/openjfx-dev/2026-January/058773.html). Enhancement requests need approval to be backported to JavaFX 26 during rampdown. You can make the request, but I don't think it is a good candidate for getting in late in the release cycle. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3764008263 From jvos at openjdk.org Sat Jan 17 15:33:10 2026 From: jvos at openjdk.org (Johan Vos) Date: Sat, 17 Jan 2026 15:33:10 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: <7NVClocOfXC0T9Rzzlc8q-zkL6qPWJz2_VhuDS1p1R0=.c258c48e-1351-48ed-98eb-c1a6ab606025@github.com> On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2042#pullrequestreview-3674226863 From fthevenet at openjdk.org Sat Jan 17 16:25:36 2026 From: fthevenet at openjdk.org (Frederic Thevenet) Date: Sat, 17 Jan 2026 16:25:36 GMT Subject: RFR: 8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration In-Reply-To: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com> Message-ID: On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet wrote: > Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system. > To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications. > > Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of. > One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative. > > GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead. > When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application. Thanks for your reply. There's one thing that remains unclear to me after going through the linked message: does the same process apply after 26 ga is released? I.e. will the bar for this enhancement still be as high if targeted at 26.0.1, provided that by then it will have "baked" into the mainline for about 5 months? Or does JavaFX not allow enhancements to be released in updates as a policy anyway? Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2025#issuecomment-3764074256 From mstrauss at openjdk.org Sat Jan 17 18:13:07 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 17 Jan 2026 18:13:07 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 21:02:04 GMT, Florian Kirmaier wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8375444 > Removed unnecessary newline modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledImpl.java line 110: > 108: //System.out.println("Text Model"); > 109: labeledImpl.setText(labeled.getText()); > 110: //System.out.println(" is truncated: " + labeled.isTextTruncated()); Please remove all of the commented-out code here. modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 49: > 47: import java.util.function.Supplier; > 48: > 49: import javafx.stage.Stage; I know that we don't specify import order, but keeping similar imports grouped is easier on the eyes... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2701328458 PR Review Comment: https://git.openjdk.org/jfx/pull/2040#discussion_r2701329404 From mmack at openjdk.org Sat Jan 17 20:52:10 2026 From: mmack at openjdk.org (Markus Mack) Date: Sat, 17 Jan 2026 20:52:10 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v3] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 20:07:43 GMT, Michael Strau? wrote: >> In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: >> >> >> public class InterruptedTransitionBug extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> var root = new StackPane(new Button("My Button")); >> var scene = new Scene(root, 600, 200); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> .button { >> transition: -fx-scale-x 2s; >> } >> >> @media (width > 300px) { >> .button { >> -fx-scale-x: 2; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> ### Problem >> First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: >> 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. >> 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. >> 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. >> >> However, when transitions come into play, this mechanism can break: >> 1. In our example, the `Button` starts with a style map that contains two properties: >> * `transition: -fx-scale-x 2s` >> * `-fx-scale-x: 2` >> 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: >> * `transition: -fx-scale-x 2s` >> 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: >> * `-fx-scale-x` is reset to `1` >> * `transition` is reset to `null` >> >> This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. >> >> ### Solution >> Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that ar... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > private equalsEndValue() implementation I tested this fix on windows 11, now all button sizes behave correctly and consistently. There seems to be another issue when defining a transition on the border color: .button { -fx-border-color: black; -fx-border-width: 5px; transition: -fx-border-color 2s; } .button:hover { -fx-border-color: blue; } @media (width > 300px) { .button { -fx-border-color: red; } } Here, the color is animated when hovering above the button, but not when changing the window size. This looks like it is related to this fix. ------------- PR Review: https://git.openjdk.org/jfx/pull/2038#pullrequestreview-3674522521 From mstrauss at openjdk.org Sat Jan 17 20:59:31 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 17 Jan 2026 20:59:31 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: References: Message-ID: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix detection of sub-properties ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2038/files - new: https://git.openjdk.org/jfx/pull/2038/files/a677800e..d8817ad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2038&range=02-03 Stats: 24 lines in 1 file changed: 23 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2038.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2038/head:pull/2038 PR: https://git.openjdk.org/jfx/pull/2038 From mstrauss at openjdk.org Sat Jan 17 21:04:16 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 17 Jan 2026 21:04:16 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 20:59:31 GMT, Michael Strau? wrote: >> In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: >> >> >> public class InterruptedTransitionBug extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> var root = new StackPane(new Button("My Button")); >> var scene = new Scene(root, 600, 200); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> .button { >> transition: -fx-scale-x 2s; >> } >> >> @media (width > 300px) { >> .button { >> -fx-scale-x: 2; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> ### Problem >> First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: >> 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. >> 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. >> 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. >> >> However, when transitions come into play, this mechanism can break: >> 1. In our example, the `Button` starts with a style map that contains two properties: >> * `transition: -fx-scale-x 2s` >> * `-fx-scale-x: 2` >> 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: >> * `transition: -fx-scale-x 2s` >> 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: >> * `-fx-scale-x` is reset to `1` >> * `transition` is reset to `null` >> >> This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. >> >> ### Solution >> Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that ar... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix detection of sub-properties The reason for this problem was that `-fx-border-color` is a sub-property of `-fx-region-border`. When we check whether properties are contained in the style map, we also need to check for sub-properties. This is now fixed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2038#issuecomment-3764335027 From mmack at openjdk.org Sat Jan 17 21:11:15 2026 From: mmack at openjdk.org (Markus Mack) Date: Sat, 17 Jan 2026 21:11:15 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 20:59:31 GMT, Michael Strau? wrote: >> In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: >> >> >> public class InterruptedTransitionBug extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> var root = new StackPane(new Button("My Button")); >> var scene = new Scene(root, 600, 200); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> .button { >> transition: -fx-scale-x 2s; >> } >> >> @media (width > 300px) { >> .button { >> -fx-scale-x: 2; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> ### Problem >> First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: >> 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. >> 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. >> 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. >> >> However, when transitions come into play, this mechanism can break: >> 1. In our example, the `Button` starts with a style map that contains two properties: >> * `transition: -fx-scale-x 2s` >> * `-fx-scale-x: 2` >> 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: >> * `transition: -fx-scale-x 2s` >> 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: >> * `-fx-scale-x` is reset to `1` >> * `transition` is reset to `null` >> >> This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. >> >> ### Solution >> Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that ar... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix detection of sub-properties Thank you for fixing this, this works well now, even when multiple css properties are animated concurrently and some of them are interrupted. Code changes look good as well. ------------- Marked as reviewed by mmack (Author). PR Review: https://git.openjdk.org/jfx/pull/2038#pullrequestreview-3674564456 From mstrauss at openjdk.org Mon Jan 19 03:47:04 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 19 Jan 2026 03:47:04 GMT Subject: RFR: 8375588: Enhanced property metadata Message-ID: Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). ### New API This PR includes the following API additions: 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. 2. The `javafx.beans.property.AttachedProperty` interface. 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. ### Testing For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. * An instance property does not implement `AttachedProperty`. * An instance property has a parameterless property getter. * An attached property implements `AttachedProperty`. * An attached property has a static single-argument property getter that accepts the target object. * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. ------------- Commit messages: - doc - Enhanced property metadata Changes: https://git.openjdk.org/jfx/pull/2015/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375588 Stats: 1804 lines in 28 files changed: 1757 ins; 6 del; 41 mod Patch: https://git.openjdk.org/jfx/pull/2015.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2015/head:pull/2015 PR: https://git.openjdk.org/jfx/pull/2015 From jhendrikx at openjdk.org Mon Jan 19 03:47:04 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 19 Jan 2026 03:47:04 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 20:56:27 GMT, Michael Strau? wrote: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. Let me say that I'd really like a mechanism such as this to be part of FX, but I do have some questions: I think the `getDeclaringClass` on `ReadOnlyProperty` is okayish; however, I'd probably never take the time to override this method with a proper value, mostly because this requires creating a subclass to be efficient. I know that within JavaFX, creating a subclass for each and every property (resulting in 1000's of subclasses) is "the standard", but for my own use, I never do this as it is just too much boilerplate. I do however have a bit of problem with `isAttached`; what does this have to do with properties in general? The description doesn't clarify what it means really, or what it even means outside the very specific case where HBox can "donate" properties to its children. So to me, the attached part feels out of place for a low-level property API, unless there are compelling reasons and other use cases we'd envision outside of having CSS stylable child properties. If not, I don't see why we shouldn't make this a method on `Stylable` or something more Node/CSS specific like in this PR: #1714 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3678804780 From mstrauss at openjdk.org Mon Jan 19 03:47:04 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 19 Jan 2026 03:47:04 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 13:40:14 GMT, John Hendrikx wrote: > I think the `getDeclaringClass` on `ReadOnlyProperty` is okayish; however, I'd probably never take the time to override this method with a proper value, mostly because this requires creating a subclass to be efficient. I know that within JavaFX, creating a subclass for each and every property (resulting in 1000's of subclasses) is "the standard", but for my own use, I never do this as it is just too much boilerplate. You can also specify it in the constructor of the `Simple*`-properties, along with the bean and name. > I do however have a bit of problem with `isAttached`; what does this have to do with properties in general? The description doesn't clarify what it means really, or what it even means outside the very specific case where HBox can "donate" properties to its children. > > So to me, the attached part feels out of place for a low-level property API, unless there are compelling reasons and other use cases we'd envision outside of having CSS stylable child properties. If not, I don't see why we shouldn't make this a method on `Stylable` or something more Node/CSS specific like in this PR: #1714 I think attached-ness is a fundamental aspect of properties, and making it visible in the type system is a logical choice. Compare this to WPF or Avalonia, where attached properties are also explicitly modelled. It's a piece of information that you can't reliably get from a property's metadata otherwise. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3679602635 From jhendrikx at openjdk.org Mon Jan 19 03:47:05 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 19 Jan 2026 03:47:05 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 22:04:58 GMT, Michael Strau? wrote: > > I do however have a bit of problem with `isAttached`; what does this have to do with properties in general? The description doesn't clarify what it means really, or what it even means outside the very specific case where HBox can "donate" properties to its children. > > So to me, the attached part feels out of place for a low-level property API, unless there are compelling reasons and other use cases we'd envision outside of having CSS stylable child properties. If not, I don't see why we shouldn't make this a method on `Stylable` or something more Node/CSS specific like in this PR: #1714 > > I think attached-ness is a fundamental aspect of properties, and making it visible in the type system is a logical choice. Compare this to WPF or Avalonia, where attached properties are also explicitly modelled. It's a piece of information that you can't reliably get from a property's metadata otherwise. I never used either framework, so "attached" is completely meaningless to me, and the description didn't enlighten me. What would this mean when I have just a bunch of properties (like a model)? It seems to me it is giving some extra information related to some kind of parent/child relationship that's outside the definition of the properties themselves. I'm only looking for a use case where this would be useful if I only have imported `javafx.base` to better understand it, and how it may benefit properties in general. I did some checking, and this was suggested by AI: - A `Task` is a simple model with a permanent property (name). - A `Workflow` defines an attached property `activeInWorkflow`, which exists only while the task is in the workflow. - `isAttached()` signals that this property is context-dependent, not intrinsic to `Task`. - Listeners or code can use `isAttached()` to safely determine whether the property is meaningful. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3679626131 From mstrauss at openjdk.org Mon Jan 19 03:47:06 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 19 Jan 2026 03:47:06 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 20:56:27 GMT, Michael Strau? wrote: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. An attached property is a property whose semantics are defined by one class, but whose value is associated with instances of another class. In other words, the declaring class "owns" the meaning, but the associated object owns the value. For example, `GridPane.columnIndex` doesn't describe anything about the `GridPane`; instead, it describes something about _another object_ as it relates to the `GridPane`. Another example is `HeaderBar.prefButtonHeight`, which is a property of `Stage`, but that property is only meaningful as it relates to `HeaderBar`. This is not a parent/child relationship and it is not primarily about CSS, it's about meaning and context. For example, you could decorate arbitrary model objects with context-specific state: an entity could be "valid" as it relates to a specific validator or rule, it could be "selected" in a specific context, or it could carry metadata (constraints, tags, flags) that is only meaningful for a particular framework. JavaFX already has this concept today, but we're not using the `Property` API to model it. Layout constraints like `GridPane.columnIndex` or `HBox.margin` are implemented as static getter/setter pairs. Since they are not first-class properties, you don't get any of the nice property features (bindings, listeners, styling, etc). If we expose attached properties with the `Property` API and you want to introspect a property, "is this intrinsic to its bean, or is it contextual/constraint-like?" is a fundamental question. The `AttachedProperty` marker interface answers that question. It's important to note that the attached property model does not come with a scope model. If I set `GridPane.columnIndex` on some child of `GridPane`, it doesn't lose that property just because it's removed from the `GridPane`. That would be a major complication that's also unexpected. I removed the `ReadOnlyProperty.isAttached()` method, and instead added the `AttachedProperty` marker interface. It can not only be used to test whether a property is an attached property, but also answers the question to which kind of object it can be attached. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3679800590 PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3690623819 From duke at openjdk.org Mon Jan 19 11:44:50 2026 From: duke at openjdk.org (Christopher Schnick) Date: Mon, 19 Jan 2026 11:44:50 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing Message-ID: The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. I tested this fix manually on Windows with a reproducer and it works as expected there ------------- Commit messages: - Improve autofix detection - Fixes - Add autofix check Changes: https://git.openjdk.org/jfx/pull/2044/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2044&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338145 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2044/head:pull/2044 PR: https://git.openjdk.org/jfx/pull/2044 From kcr at openjdk.org Mon Jan 19 14:03:32 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 19 Jan 2026 14:03:32 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. @HimaBinduMeda Please wait for me to review / test this before integrating. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2042#issuecomment-3768477302 From fkirmaier at openjdk.org Tue Jan 20 08:41:45 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 20 Jan 2026 08:41:45 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v4] In-Reply-To: References: Message-ID: > For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. > > This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. > I've also extended the existing tests for the truncated property. > > It would be great, to get some feedback on how i fixes the bug. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8375444 Removed commented out print statements. Fixed import order. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2040/files - new: https://git.openjdk.org/jfx/pull/2040/files/4f7416ae..6f78c578 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2040&range=02-03 Stats: 9 lines in 2 files changed: 1 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2040.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2040/head:pull/2040 PR: https://git.openjdk.org/jfx/pull/2040 From crschnick at xpipe.io Tue Jan 20 13:33:40 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 20 Jan 2026 14:33:40 +0100 Subject: StageStyle.EXTENDED with transparent background In-Reply-To: References: Message-ID: <1da94f9c-f3a2-47b2-92de-641b33ef39b2@xpipe.io> I experimented with this myself and created the draft PR https://github.com/openjdk/jfx/pull/2045. If you like, you can try it out. I think at least that this is the issue you described. I haven't evaluated all the consequences of this yet and only tested it on Windows. But there it works as expected for me On 21/10/2025 05:00, Glavo wrote: > 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 lukasz.kostyra at oracle.com Tue Jan 20 14:40:31 2026 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Tue, 20 Jan 2026 14:40:31 +0000 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <2f171928-1f91-4dc7-be35-ca447fc5d712@xpipe.io> <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io> <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> Message-ID: Hi Christopher, After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. Regards, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Wednesday, 10 December 2025 13:29 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release It should work fine without the property. Thanks for your help, I?ll keep searching. -Lukasz From: Christopher Schnick > Sent: Tuesday, 9 December 2025 17:10 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. Or should I still pass the property in this commit as well? On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: Hi Christopher, I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. Thanks, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Thursday, 4 December 2025 11:52 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. -Lukasz From: Christopher Schnick > Sent: Wednesday, 3 December 2025 18:53 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: Hi Christopher, I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. Thanks, -Lukasz From: Christopher Schnick Sent: Friday, 28 November 2025 13:25 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I did not encounter the vanishing issue anymore with that build, so at least it is usable. However, the font rendering issue still exists for some nodes: [cid:image001.png at 01DC8A23.1A262C30] It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. On 28/11/2025 12:41, Lukasz Kostyra wrote: Hi Christopher, I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Monday, 17 November 2025 15:14 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it. On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. -Lukasz From: Christopher Schnick > Sent: Saturday, 15 November 2025 17:39 To: Lukasz Kostyra > Cc: OpenJFX > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release Forgot to add, there is nothing out of the ordinary printed in the verbose logs. If I find the time, I can look into compiling a debug build. But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. On 15/11/2025 17:34, Christopher Schnick wrote: Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: [cid:image002.png at 01DC8A23.1A262C30] Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. On 13/11/2025 16:30, Lukasz Kostyra wrote: Thanks for checking. It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. Good luck! - Lukasz From: Christopher Schnick Sent: Thursday, 13 November 2025 16:11 To: Lukasz Kostyra Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. There is no exception thrown as far as I can see, so not sure what you need for debugging. For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx On 13/11/2025 14:40, Lukasz Kostyra wrote: Hello openjfx-dev, The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/ Please test this bundle and share your feedback by: - emailing openjfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. 3. It is recommended to use JDK 25 or later. 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. 5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Lukasz Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: image002.png URL: From kcr at openjdk.org Tue Jan 20 15:02:48 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:02:48 GMT Subject: [jfx25u] RFR: Merge 25a5cdc6f2254c47525fa8b98d6bbab711c7ee5e Message-ID: Clean merge of January 2026 CPU content into `jfx25u:master`. Reviewer: @johanvos ------------- Commit messages: - Merge branch 'jfx25.0.2' into merge-jfx25.0.2 - Merge - Merge - Merge - Merge - 8368704: Better glyph handling - 8362535: Update libxslt support - 8368600: Missing "/DELAYLOAD:shlwapi.dll" in win.gradle - Merge - 8361719: Enhance Handling of URIs - ... and 4 more: https://git.openjdk.org/jfx25u/compare/67b4c5b7...da32c42a The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx25u/pull/44/files Stats: 284 lines in 16 files changed: 236 ins; 28 del; 20 mod Patch: https://git.openjdk.org/jfx25u/pull/44.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/44/head:pull/44 PR: https://git.openjdk.org/jfx25u/pull/44 From kcr at openjdk.org Tue Jan 20 15:03:27 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:03:27 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 [v2] In-Reply-To: References: Message-ID: <5wFo81igdy34GeuREohr7s2vPZq48Jd2Qj45D_DuV_E=.6fd4096c-ed1e-4699-b7c5-5bd0835ca467@github.com> > 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=48169 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=48168 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2026-01-20, 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: Security content ------------- Changes: - all: https://git.openjdk.org/jfx25u/pull/43/files - new: https://git.openjdk.org/jfx25u/pull/43/files/eb7e34ae..7b7e7c70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx25u&pr=43&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx25u&pr=43&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx25u/pull/43.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/43/head:pull/43 PR: https://git.openjdk.org/jfx25u/pull/43 From jvos at openjdk.org Tue Jan 20 15:08:10 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:08:10 GMT Subject: [jfx25u] RFR: Merge 25a5cdc6f2254c47525fa8b98d6bbab711c7ee5e In-Reply-To: References: Message-ID: <8G6Du4kIgJlaNgIR98tJhUYsla6Y9gWH-GPIro9lo5Q=.915b775e-8a9f-4b35-845a-2107fa1b69ae@github.com> On Tue, 20 Jan 2026 14:55:39 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx25u:master`. > > Reviewer: @johanvos Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx25u/pull/44#pullrequestreview-3682669274 From kcr at openjdk.org Tue Jan 20 15:08:39 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:08:39 GMT Subject: [jfx26] RFR: Merge eac8ccbc05cc28c702c967c66add77d296c20737 Message-ID: Clean merge of January 2026 CPU content into `jfx:jfx26`. Reviewer: @johanvos ------------- Commit messages: - Merge - Merge - Merge - Merge - Merge - Merge - 8368704: Better glyph handling - 8362535: Update libxslt support - 8368600: Missing "/DELAYLOAD:shlwapi.dll" in win.gradle - Merge - ... and 2 more: https://git.openjdk.org/jfx/compare/192929b4...eac8ccbc The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/2047/files Stats: 289 lines in 17 files changed: 241 ins; 28 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/2047.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2047/head:pull/2047 PR: https://git.openjdk.org/jfx/pull/2047 From kcr at openjdk.org Tue Jan 20 15:08:44 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:08:44 GMT Subject: RFR: Merge eac8ccbc05cc28c702c967c66add77d296c20737 Message-ID: <2Y5jFrfWFRHlRbe0KZrSaAe9vDYR8Fr0BSptr8AU4Ro=.7b645b32-ad2f-48e5-aa64-ed3aa8e8da27@github.com> Clean merge of January 2026 CPU content into `jfx:master`. Reviewer: @johanvos ------------- Commit messages: - Merge branch 'jfx27-cpu-2601' into merge-jfx27-cpu-2601 - Merge - Merge - Merge - Merge - Merge - Merge - 8368704: Better glyph handling - 8362535: Update libxslt support - 8368600: Missing "/DELAYLOAD:shlwapi.dll" in win.gradle - ... and 3 more: https://git.openjdk.org/jfx/compare/40c0292b...502abd03 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx/pull/2046/files Stats: 289 lines in 17 files changed: 241 ins; 28 del; 20 mod Patch: https://git.openjdk.org/jfx/pull/2046.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2046/head:pull/2046 PR: https://git.openjdk.org/jfx/pull/2046 From jvos at openjdk.org Tue Jan 20 15:08:45 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:08:45 GMT Subject: RFR: Merge eac8ccbc05cc28c702c967c66add77d296c20737 In-Reply-To: <2Y5jFrfWFRHlRbe0KZrSaAe9vDYR8Fr0BSptr8AU4Ro=.7b645b32-ad2f-48e5-aa64-ed3aa8e8da27@github.com> References: <2Y5jFrfWFRHlRbe0KZrSaAe9vDYR8Fr0BSptr8AU4Ro=.7b645b32-ad2f-48e5-aa64-ed3aa8e8da27@github.com> Message-ID: <0Y2J5taYnw2CwPR_nDo9TihMZQh7KAd_dB989jPI8PM=.cd860f53-e0e9-436b-8e67-f7462f5348ac@github.com> On Tue, 20 Jan 2026 14:59:29 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx:master`. > > Reviewer: @johanvos Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2046#pullrequestreview-3682655672 From jvos at openjdk.org Tue Jan 20 15:17:01 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:17:01 GMT Subject: [jfx26] RFR: Merge eac8ccbc05cc28c702c967c66add77d296c20737 In-Reply-To: References: Message-ID: <0zANKyvkkaSUv0QlQDaMiWARCgjYPwPA_JG744uXnD0=.01041a0f-99d7-4489-8dbd-f4571f68530a@github.com> On Tue, 20 Jan 2026 14:59:54 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx:jfx26`. > > Reviewer: @johanvos Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2047#pullrequestreview-3682709831 From jvos at openjdk.org Tue Jan 20 15:20:43 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:20:43 GMT Subject: [jfx17u] RFR: Merge 3f57e6213a1554b266a9179850038af56d24ac29 Message-ID: Clean merge of January 2026 CPU content into jfx17u:master. ------------- Commit messages: - Clean merge of the January CPU content into jfx17u:master The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx17u/pull/245/files Stats: 277 lines in 16 files changed: 235 ins; 21 del; 21 mod Patch: https://git.openjdk.org/jfx17u/pull/245.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/245/head:pull/245 PR: https://git.openjdk.org/jfx17u/pull/245 From jvos at openjdk.org Tue Jan 20 15:21:06 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:21:06 GMT Subject: [jfx21u] RFR: Merge 46ca2bddc12d85d98f306ef0ccfcb1f478881fb2 Message-ID: Clean merge of January 2026 CPU content into jfx21u:master. ------------- Commit messages: - Clean merge of January CPU content into jfx21u:master The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx21u/pull/108/files Stats: 284 lines in 16 files changed: 236 ins; 28 del; 20 mod Patch: https://git.openjdk.org/jfx21u/pull/108.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/108/head:pull/108 PR: https://git.openjdk.org/jfx21u/pull/108 From jvos at openjdk.org Tue Jan 20 15:23:43 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:23:43 GMT Subject: [jfx25u] RFR: 8375235: Create release notes for JavaFX 25.0.2 [v2] In-Reply-To: <5wFo81igdy34GeuREohr7s2vPZq48Jd2Qj45D_DuV_E=.6fd4096c-ed1e-4699-b7c5-5bd0835ca467@github.com> References: <5wFo81igdy34GeuREohr7s2vPZq48Jd2Qj45D_DuV_E=.6fd4096c-ed1e-4699-b7c5-5bd0835ca467@github.com> Message-ID: <1MMN-MTG5_z021G-KmM98GJ5edheJHcyJHBYJJ9Kq9M=.be7c53d2-a614-41e9-804c-e17e7c546b66@github.com> On Tue, 20 Jan 2026 15:03:27 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=48169 >> >> The original filter, with the backport IDs, is here: >> >> https://bugs.openjdk.org/issues/?filter=48168 >> >> As usual, I excluded test bugs, cleanup bugs, etc. >> >> NOTE: Once the CPU release ships on 2026-01-20, 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: > > Security content Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx25u/pull/43#pullrequestreview-3682753433 From crschnick at xpipe.io Tue Jan 20 15:24:25 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Tue, 20 Jan 2026 16:24:25 +0100 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io> <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> Message-ID: <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> In our main application I am getting the following error spammed in the logs: 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) 16:18:08:572 - error:? ? ?at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) 16:18:08:572 - error:? ? ?at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) 16:18:08:572 - error:? ? ?at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) 16:18:08:572 - error:? ? ?at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. On 20/01/2026 15:40, Lukasz Kostyra wrote: > > Hi Christopher, > > After Christmas break I came back to this issue with some new patches. > There were some problems I found with the clear optimization, I just > submitted > https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 > and according to my local testing everything seems to be fine now. > > When you have a moment, could you check out the changes above and let > me know if everything works correctly in your app? > > If there are still problems I would like to find a way to build your > app and test it locally. I tried doing that earlier via > https://github.com/xpipe-io/kickstartfx > > you linked earlier but encountered some problems when building, so I?m > going to need your help or some instructions on how to build the app. > > Regards, > > -Lukasz > > *From:*openjfx-dev *On Behalf Of > *Lukasz Kostyra > *Sent:* Wednesday, 10 December 2025 13:29 > *To:* Christopher Schnick > *Cc:* OpenJFX > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > It should work fine without the property. Thanks for your help, I?ll > keep searching. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Tuesday, 9 December 2025 17:10 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > I tried this commit, but the problem shows up again. I tested the > previous commit with the passed property again, and that one still works. > > Or should I still pass the property in this commit as well? > > On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I updated the direct3d12 branch with the fix - > https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 > > . Let me know how it works and if the problem has been resolved. > > Thanks, > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of *Lukasz Kostyra > *Sent:* Thursday, 4 December 2025 11:52 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > Thanks for checking. I filed > https://bugs.openjdk.org/browse/JDK-8373088 to track this since > this is unrelated to specifically text, will probably get to it in > a few days. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Wednesday, 3 December 2025 18:53 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > This commit fixes the problem when the property is set to false > and it shows up again if the property is not set to false > > On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I did not find the way to reproduce this locally, but I found > a problem with one of the optimizations that is in the > backend. To double check if that is in fact the issue I pushed > https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 > > to disable the optimization (it is on by default, disabling it > fixes that specific problem on my end) and I?d like to > double-check if this is the correct lead. > > When you have a moment, could you build JFX with that change > and run your app with ?-Dprism.d3d12.clearOpts=false? added to > the command line? > > If the problem persists with prism.d3d12.clearOpts set to > false I would need some more information on how these labels > are rendered to track this down. > > Thanks, > > -Lukasz > > *From:*Christopher Schnick > > *Sent:* Friday, 28 November 2025 13:25 > *To:* Lukasz Kostyra > > *Cc:* OpenJFX > > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > I did not encounter the vanishing issue anymore with that > build, so at least it is usable. > > However, the font rendering issue still exists for some nodes: > > It is not deterministic, meaning that if I just scroll the > scrollpane forward and back, the same text might get rendered > correctly. > > Also, did you see the performance results I posted for my AMD > system? Performance was quite bad there, so this is not in a > stage where I can test this in production a bit. > > On 28/11/2025 12:41, Lukasz Kostyra wrote: > > Hi Christopher, > > I just pushed a fix for JDK-8371995 onto direct3d12 branch > in the sandbox - > https://github.com/openjdk/jfx-sandbox/tree/direct3d12 > > . If you find a moment, could you build JFX from that > branch and check if your app works correctly? > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of > *Lukasz Kostyra > *Sent:* Monday, 17 November 2025 15:14 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > I might?ve found the problem, there is an assertion that > triggers when multiple text objects using different fonts > are drawn. It could be related (AFAIK Label controls will > eventually end up at the same text rendering routines as > Text nodes). Assertions are compiled out on Release for > performance, so there is a chance it would corrupt the > rendering without anything meaningful shown on screen. > > To track this I just filed > https://bugs.openjdk.org/browse/JDK-8371995 . I will check > it and let you know when I fix it. > > On your side It might still be handy to build JFX in > DebugNative, to confirm if the triggered assertion is the > same and to later confirm if the fix is working for you too. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Saturday, 15 November 2025 17:39 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* Re: [External] : Re: JavaFX Direct3D 12 - > Second EA release > > Forgot to add, there is nothing out of the ordinary > printed in the verbose logs. > > If I find the time, I can look into compiling a debug build. > > But the problem should be reproducible somehow when just > automatically creating a lot of labels with random styles, > sizes, and text. Some of them should break as they did for me. > > On 15/11/2025 17:34, Christopher Schnick wrote: > > Ok, so I had more time to debug it. The one weird > thing I observed when it was working was that some > labels have corrupted text rendering: > > > Not all of them, most are fine. There are no > differences in terms of style classes etc. between the > labels. When scrolling, the rendering sometimes > switches between this corrupted and normal state after > some delay. > > After a while I also figured out that text rendering > is responsible for the issue of the nodes vanishing: > Certain label contents broke the renderer. For > example, in my application, the string "Password > manager" when assigned to a label broke it and nothing > was rendered anymore. I tried to find an easy > reproducer but was not able to. It's probably very > dependent on all the different style classes that > influence the text shape/size/etc. > > On 13/11/2025 16:30, Lukasz Kostyra wrote: > > Thanks for checking. > > It is very possible the D3D12 runtime did not like > something, could be related to your specific > hardware. D3D12 by now has many extensions which > differ depending on hardware and can lift certain > restrictions - we already internally had a case > where one GPU had some restriction that was not > enforced on another GPU and we had to accommodate > that. > > The first step would be to try running D3D12 with > ?-Dprism.verbose=true -Dprism.debug=true?. These > should print additional logs that might have some > extra information. > > If there?s nothing useful there, next step would > be to build JavaFX with -PCONF=DebugNative - this > will compile shaders in Debug, add assertions and > debug logs to the backend - and then run your app > with D3D12 debug layers and GPU debugging enabled > by adding ?-Dprsim.d3d12.debugLayers=true > -Dprism.d3d12.gpuDebug=true?. Those will slow down > the app significantly, but will also tell D3D12 to > run additional API use and GPU use checks. > > If the problem happens during a render loop and > debug layers catch it, there is a chance it will > cascade into other errors and spam the console > output - you can tell D3D12 debug layers to > trigger an assertion on first encountered error > with ?-Dprism.d3d12.breakOnError=true?. > > I am running out of time today to check this > myself, but if you find something let me know - > I?ll try to reproduce the problem myself and we?ll > see where we go from there. > > Good luck! > > - Lukasz > > *From:*Christopher Schnick > > *Sent:* Thursday, 13 November 2025 16:11 > *To:* Lukasz Kostyra > > *Cc:* openjfx-dev at openjdk.org > *Subject:* [External] : Re: JavaFX Direct3D 12 - > Second EA release > > I just tried to run a project with provided jmods > and at some point, certain nodes are just not > rendered anymore and the window contents vanish. > But they render for a short period of time. > > There is no exception thrown as far as I can see, > so not sure what you need for debugging. > > For testing, this is the built application with > the d3d12 jmods that you can use to attempt to > reproduce the problem: https://we.tl/t-DJuX0BeqXm > > . It is built from these sources: > https://github.com/xpipe-io/kickstartfx > > > On 13/11/2025 14:40, Lukasz Kostyra wrote: > > Hello openjfx-dev, > > The second Early Access(EA) build of JavaFX > with the Windows Direct3D 12 rendering > pipeline is now available at: > https://jdk.java.net/javafxdirect3d12/ > > > Please test this bundle and share your > feedback by: > > - emailing openjfx-dev at openjdk.java.net or > > - reporting issues via > JBS[https://bugs.openjdk.org/] or at > https://bugreport.java.com > > > This is the second EA release. The backend is > feature-complete and went through a first > optimization pass, but it still requires some > more testing on more hardware variants before > we can consider it complete. As such, with > this release we also would like to call for > help with performance testing the backend > (more details on that will be sent in a > separate email thread). > > Known issues and pending tasks are captured on > JBS and can be accessed using the filter > provided on the Direct3D 12 EA page > [https://jdk.java.net/javafxdirect3d12/ > ]. > Before reporting a new bug, please review the > existing issues to avoid duplicates. > > Important Notes: > > 1. This is a Windows-specific feature, so only > a Windows-specific bundle is provided. > > 2. The default rendering pipeline is set to > d3d12. Use "-Dprism.order=d3d" or > "-Dprism.order=sw" to select one of the other > pipelines for comparison testing. > > 3. It is recommended to use JDK 25 or later. > > 4. At this stage D3D12 backend is > feature-complete and went through the first > phase of optimization. It is worth noting > that, while generally we noticed performance > improvements, it might not be on par with D3D > backend on every machine combo? - we already > noted performance being worse on recent NVidia > discrete GPUs > [https://bugs.openjdk.org/browse/JDK-8370486] > and are looking for solutions. > > 5. Issue behavior may vary across different > hardware, so please provide detailed > information, such as the output of "java > -Dprism.verbose=true" or used hardware, when > reporting or discussing issues. > > 6. Refer: Run HelloWorld using JavaFX SDK > [https://openjfx.io/openjfx-docs/#install-javafx > ] > > We look forward to your feedback. > > Regards, > > Lukasz > > Confidential- Oracle Internal > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: not available URL: From jvos at openjdk.org Tue Jan 20 15:40:50 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:40:50 GMT Subject: [jfx21u] RFR: Merge 46ca2bddc12d85d98f306ef0ccfcb1f478881fb2 [v2] In-Reply-To: References: Message-ID: > Clean merge of January 2026 CPU content into jfx21u:master. Johan Vos 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. ------------- Changes: - all: https://git.openjdk.org/jfx21u/pull/108/files - new: https://git.openjdk.org/jfx21u/pull/108/files/46ca2bdd..46ca2bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx21u&pr=108&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx21u&pr=108&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/108.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/108/head:pull/108 PR: https://git.openjdk.org/jfx21u/pull/108 From jvos at openjdk.org Tue Jan 20 15:43:05 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:43:05 GMT Subject: [jfx21u] Integrated: Merge 46ca2bddc12d85d98f306ef0ccfcb1f478881fb2 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 15:08:49 GMT, Johan Vos wrote: > Clean merge of January 2026 CPU content into jfx21u:master. This pull request has now been integrated. Changeset: 05bfb060 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/05bfb060d928ba12d4aa757ab77ba88e3b05ba8f Stats: 284 lines in 16 files changed: 236 ins; 28 del; 20 mod Merge JDK-8361719 JDK-8368600 JDK-8362535 JDK-8368704 ------------- PR: https://git.openjdk.org/jfx21u/pull/108 From jvos at openjdk.org Tue Jan 20 15:49:23 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:49:23 GMT Subject: [jfx17u] RFR: Merge 3f57e6213a1554b266a9179850038af56d24ac29 [v2] In-Reply-To: References: Message-ID: <-xh_CvsbrAfT2TzMtRfPpMlVKQj4TooOOciB3wrm2-s=.ae909753-1f31-49d9-bbb5-0948f1b79ffc@github.com> > Clean merge of January 2026 CPU content into jfx17u:master. Johan Vos 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. ------------- Changes: - all: https://git.openjdk.org/jfx17u/pull/245/files - new: https://git.openjdk.org/jfx17u/pull/245/files/3f57e621..3f57e621 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx17u&pr=245&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx17u&pr=245&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/245.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/245/head:pull/245 PR: https://git.openjdk.org/jfx17u/pull/245 From jvos at openjdk.org Tue Jan 20 15:49:24 2026 From: jvos at openjdk.org (Johan Vos) Date: Tue, 20 Jan 2026 15:49:24 GMT Subject: [jfx17u] Integrated: Merge 3f57e6213a1554b266a9179850038af56d24ac29 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 15:09:26 GMT, Johan Vos wrote: > Clean merge of January 2026 CPU content into jfx17u:master. This pull request has now been integrated. Changeset: 1edd83c8 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/1edd83c841430b4d35a984dfe3821285f3904bf8 Stats: 277 lines in 16 files changed: 235 ins; 21 del; 21 mod Merge JDK-8361719 JDK-8368600 JDK-8362535 JDK-8368704 ------------- PR: https://git.openjdk.org/jfx17u/pull/245 From kcr at openjdk.org Tue Jan 20 15:50:21 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:50:21 GMT Subject: [jfx25u] Integrated: Merge 25a5cdc6f2254c47525fa8b98d6bbab711c7ee5e In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 14:55:39 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx25u:master`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: 631c259e Author: Kevin Rushforth URL: https://git.openjdk.org/jfx25u/commit/631c259e7278908c306ecff6a672bcebce849c62 Stats: 284 lines in 16 files changed: 236 ins; 28 del; 20 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx25u/pull/44 From kcr at openjdk.org Tue Jan 20 15:58:05 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 15:58:05 GMT Subject: [jfx25u] Integrated: 8375235: Create release notes for JavaFX 25.0.2 In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 12:34:15 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=48169 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=48168 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2026-01-20, I will add any security bugs and ask for a re-review. This pull request has now been integrated. Changeset: b7389987 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx25u/commit/b738998795ddbd963484e9ea76c0f36c3c08b50d Stats: 45 lines in 1 file changed: 45 ins; 0 del; 0 mod 8375235: Create release notes for JavaFX 25.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx25u/pull/43 From kcr at openjdk.org Tue Jan 20 16:03:02 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 16:03:02 GMT Subject: [jfx26] Integrated: Merge eac8ccbc05cc28c702c967c66add77d296c20737 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 14:59:54 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx:jfx26`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: 279fcdd3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/279fcdd38f6985178d65e415a0bbc119c7d34ba6 Stats: 289 lines in 17 files changed: 241 ins; 28 del; 20 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/2047 From kcr at openjdk.org Tue Jan 20 16:03:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 16:03:01 GMT Subject: [jfx26] RFR: Merge eac8ccbc05cc28c702c967c66add77d296c20737 [v2] In-Reply-To: References: Message-ID: > Clean merge of January 2026 CPU content into `jfx:jfx26`. > > Reviewer: @johanvos 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. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2047/files - new: https://git.openjdk.org/jfx/pull/2047/files/eac8ccbc..eac8ccbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2047&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2047&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2047.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2047/head:pull/2047 PR: https://git.openjdk.org/jfx/pull/2047 From kcr at openjdk.org Tue Jan 20 16:01:41 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 16:01:41 GMT Subject: Integrated: Merge eac8ccbc05cc28c702c967c66add77d296c20737 In-Reply-To: <2Y5jFrfWFRHlRbe0KZrSaAe9vDYR8Fr0BSptr8AU4Ro=.7b645b32-ad2f-48e5-aa64-ed3aa8e8da27@github.com> References: <2Y5jFrfWFRHlRbe0KZrSaAe9vDYR8Fr0BSptr8AU4Ro=.7b645b32-ad2f-48e5-aa64-ed3aa8e8da27@github.com> Message-ID: On Tue, 20 Jan 2026 14:59:29 GMT, Kevin Rushforth wrote: > Clean merge of January 2026 CPU content into `jfx:master`. > > Reviewer: @johanvos This pull request has now been integrated. Changeset: 8deb5160 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/8deb516092e552827ff189a1e2ebf5b1aa265e26 Stats: 289 lines in 17 files changed: 241 ins; 28 del; 20 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx/pull/2046 From angorya at openjdk.org Tue Jan 20 16:38:05 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 16:38:05 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: References: Message-ID: <45JwYvVvWkvvZBNJtfDvYiq-Xi5WcA9-lXNhZCaC4mU=.b5ee63fd-fb10-4566-96f1-d70dc016f094@github.com> On Sat, 17 Jan 2026 20:59:31 GMT, Michael Strau? wrote: >> In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: >> >> >> public class InterruptedTransitionBug extends Application { >> @Override >> public void start(Stage stage) throws Exception { >> var root = new StackPane(new Button("My Button")); >> var scene = new Scene(root, 600, 200); >> scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" >> .button { >> transition: -fx-scale-x 2s; >> } >> >> @media (width > 300px) { >> .button { >> -fx-scale-x: 2; >> } >> } >> """.getBytes(StandardCharsets.UTF_8))); >> stage.setScene(scene); >> stage.show(); >> } >> } >> >> >> ### Problem >> First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: >> 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. >> 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. >> 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. >> >> However, when transitions come into play, this mechanism can break: >> 1. In our example, the `Button` starts with a style map that contains two properties: >> * `transition: -fx-scale-x 2s` >> * `-fx-scale-x: 2` >> 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: >> * `transition: -fx-scale-x 2s` >> 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: >> * `-fx-scale-x` is reset to `1` >> * `transition` is reset to `null` >> >> This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. >> >> ### Solution >> Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that ar... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix detection of sub-properties one very minor suggestion, though it's perfectly fine if you leave it as is. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 550: > 548: } > 549: > 550: for (int i = 0, max = subProperties.size(); i < max; ++i) { very, very minor: since the order probably does not matter: for (int i = subProperties.size() - 1, i >= 0; --i) { ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2038#pullrequestreview-3683134570 PR Review Comment: https://git.openjdk.org/jfx/pull/2038#discussion_r2709145830 From mstrauss at openjdk.org Tue Jan 20 16:51:39 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 16:51:39 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: <45JwYvVvWkvvZBNJtfDvYiq-Xi5WcA9-lXNhZCaC4mU=.b5ee63fd-fb10-4566-96f1-d70dc016f094@github.com> References: <45JwYvVvWkvvZBNJtfDvYiq-Xi5WcA9-lXNhZCaC4mU=.b5ee63fd-fb10-4566-96f1-d70dc016f094@github.com> Message-ID: On Tue, 20 Jan 2026 16:32:05 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fix detection of sub-properties > > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 550: > >> 548: } >> 549: >> 550: for (int i = 0, max = subProperties.size(); i < max; ++i) { > > very, very minor: since the order probably does not matter: > > > for (int i = subProperties.size() - 1, i >= 0; --i) { The order doesn't matter, but with reverse iteration, I always stop to think whether that tells me something important. Someone recently said: why do you force me to think? ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2038#discussion_r2709197189 From mstrauss at openjdk.org Tue Jan 20 16:51:40 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 16:51:40 GMT Subject: Integrated: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 03:11:11 GMT, Michael Strau? wrote: > In the following program, resizing the window to be smaller than 300px should start a transition for `-fx-scale-x` from 2 to 1, but instead the value sometimes snaps back to 1 instantly: > > > public class InterruptedTransitionBug extends Application { > @Override > public void start(Stage stage) throws Exception { > var root = new StackPane(new Button("My Button")); > var scene = new Scene(root, 600, 200); > scene.getStylesheets().add("data:text/css;base64," + Base64.getEncoder().encodeToString(""" > .button { > transition: -fx-scale-x 2s; > } > > @media (width > 300px) { > .button { > -fx-scale-x: 2; > } > } > """.getBytes(StandardCharsets.UTF_8))); > stage.setScene(scene); > stage.show(); > } > } > > > ### Problem > First, let's look at how `CssStyleHelper` works when the cascading style map for a node changes: > 1. When the style map for a node has changed, `StyleHelper.createStyleHelper(Node)` determines that the style helper is no longer any good, and a new `CssStyleHelper` for the new style map is created. > 2. Before the old style helper is discarded, it calls `CssStyleHelper.resetToInitialValues(Styleable)` and resets all properties that were set by this style helper back to their initial values. This ensures that the new style helper has a "clean slate" to work from. > 3. The next `Node.applyCss()` pass will now set the properties that are specified in the new style map to their new values. > > However, when transitions come into play, this mechanism can break: > 1. In our example, the `Button` starts with a style map that contains two properties: > * `transition: -fx-scale-x 2s` > * `-fx-scale-x: 2` > 2. Due to a changing media query, this is replaced with a style map that only contains a single entry: > * `transition: -fx-scale-x 2s` > 3. Before the new style map is applied, all properties affected by the old style map are reset to their initial values. That means: > * `-fx-scale-x` is reset to `1` > * `transition` is reset to `null` > > This is where it breaks: if `transition` is reset before `-fx-scale-x`, the latter will see no transition when its value is set back to `1`. > > ### Solution > Simply resetting all properties back to their initial values when a style map is changed is not necessary. We only need to reset the properties that are set by the old style map, but are no longer set by the new style map. In our example, si... This pull request has now been integrated. Changeset: f617ac7e Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/f617ac7e1b6c0170fb0d47b4ad8a423a4d713bb4 Stats: 424 lines in 10 files changed: 378 ins; 16 del; 30 mod 8375363: StyleHelper.resetToInitialValues() interrupts animated properties Reviewed-by: angorya, mmack ------------- PR: https://git.openjdk.org/jfx/pull/2038 From tsayao at openjdk.org Tue Jan 20 17:10:39 2026 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 20 Jan 2026 17:10:39 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v71] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 21:00:47 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 85 commits: > > - Merge branch 'master' into 8354943 > > # Conflicts: > # tests/system/src/test/java/test/util/Util.java > - Merge branch 'master' into 8354943 > - Remote assumeTrue for JDK-8364547 > - Merge branch 'master' into 8354943 > - 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 > - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205 I was away on vacation. Will get back to this soon. I've been using this PR for a while on my daily job and it seems all good (but there's always edge cases). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3774005877 From angorya at openjdk.org Tue Jan 20 17:33:07 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 17:33:07 GMT Subject: RFR: 8375363: StyleHelper.resetToInitialValues() interrupts animated properties [v4] In-Reply-To: References: <45JwYvVvWkvvZBNJtfDvYiq-Xi5WcA9-lXNhZCaC4mU=.b5ee63fd-fb10-4566-96f1-d70dc016f094@github.com> Message-ID: On Tue, 20 Jan 2026 16:45:17 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 550: >> >>> 548: } >>> 549: >>> 550: for (int i = 0, max = subProperties.size(); i < max; ++i) { >> >> very, very minor: since the order probably does not matter: >> >> >> for (int i = subProperties.size() - 1, i >= 0; --i) { > > The order doesn't matter, but with reverse iteration, I always stop to think whether that tells me something important. > > Someone recently said: why do you force me to think? ? Touch? :-) I usually use the reverse order to save 8 bytes (`int max`), but I actually _don't know_ whether it saves - one has to look at the bytecode or better yet, at the produced assembly to see if there is such a saving. but in any case, since it's not a heap allocation, there is probably very little difference anyway. I'll show myself out. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2038#discussion_r2709361511 From mstrauss at openjdk.org Tue Jan 20 17:38:10 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 17:38:10 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 22:25:29 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with three additional commits since the last revision: > > - Remove space > - Use for loops again > - Remove unused method modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 212: > 210: * @param blendMode cannot be null > 211: */ > 212: public void setBlendMode(Object blendMode) { It seems like group blend modes were [removed](https://bugs.openjdk.org/browse/JDK-8113442) a long time ago. You should also delete all of the implementation, not only the setter here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2709392547 From kcr at openjdk.org Tue Jan 20 18:18:13 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 18:18:13 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. @HimaBinduMeda There is a minor merge issue that will need to be fixed up following the recent integration of the changes from PR #2047 . To address this, do the following: 1. Merge in the latest jfx master. 2. Apply the following patch: --- a/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp +++ b/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp @@ -499,7 +499,7 @@ void ComplexTextController::ComplexTextRun::setIsNonMonotonic() #else for (unsigned i = 0; i < m_glyphCount; ++i) { // Skip zero-width glyphs if needed - if (m_font.isZeroWidthSpaceGlyph(m_glyphs[i])) + if (m_font->isZeroWidthSpaceGlyph(m_glyphs[i])) continue; // Handle out of bound case unsigned charIndex = indexAt(i); I've already tested it both locally, and in our CI, so I'll just run a sanity test once you update the PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2042#issuecomment-3774287766 From angorya at openjdk.org Tue Jan 20 18:46:42 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 18:46:42 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:37:20 GMT, Christopher Schnick wrote: > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 490: > 488: // The popup does not directly store information on whether it was autofixed > 489: // We can determine this by looking whether it was moved upward > 490: boolean wasAutofixed = popup.getY() < getSkinnable().localToScreen(0, 0).getY(); what does this mean? the popup was auto-fixed, but incorrectly? should we change the auto-fixing code instead then? alternatively, is it possible that we should adjust the popup each time instead of adding the 'first' argument? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2044#discussion_r2709643894 From angorya at openjdk.org Tue Jan 20 19:06:06 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 19:06:06 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:37:20 GMT, Christopher Schnick wrote: > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there The fix does not look right, perhaps we need to change the auto-fix code instead. Here is what I see on macOS using these steps: - open the reproducer - move the window down such that the combo box bottom edge goes beyond the lower screen boundary - click to show the popup ==> the popup appears way too high: Screenshot 2026-01-20 at 10 58 33 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2044#issuecomment-3774480821 From angorya at openjdk.org Tue Jan 20 19:30:17 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 19:30:17 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 00:26:31 GMT, Michael Strau? wrote: > JavaFX already has this concept today, but we're not using the `Property` API to model it. Layout constraints like `GridPane.columnIndex` or `HBox.margin` are implemented as static getter/setter pairs. Since they are not first-class properties, you don't get any of the nice property features (bindings, listeners, styling, etc). I always found this design to be weird and unnecessary - these should be the properties/constraints of the container or the layout, not something stored in the child nodes. What happens when the said child is moved from one container to another?? It might be just me, but I fail to see the value of this proposal. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3774569552 From mstrauss at openjdk.org Tue Jan 20 19:50:14 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 19:50:14 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:25:42 GMT, Andy Goryachev wrote: > I always found this design to be weird and unnecessary - these should be the properties/constraints of the container or the layout, not something stored in the child nodes. What happens when the said child is moved from one container to another?? > > It might be just me, but I fail to see the value of this proposal. This is not a good argument against this proposal, as JavaFX has always had attached properties and they're not going away. This just makes the existing concept more useful by using the `Property` API instead of simple getters and setters. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3774647472 From angorya at openjdk.org Tue Jan 20 20:02:21 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 20:02:21 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 20:56:27 GMT, Michael Strau? wrote: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. Not going away - possibly. But it does not change the fact that these properties are stored in the wrong place. Adding some sort of band-aid code to help with some use cases seems a bit wrong to me. It does not mean that we don't have the actual problem. Perhaps you could describe a couple of use cases where the new API would shine, use cases where it is impossible to achieve the goal using the existing APIs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3774684544 From angorya at openjdk.org Tue Jan 20 20:13:54 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 20:13:54 GMT Subject: RFR: 8373452: DataFormat threading and API issues Message-ID: ### Summary This PR makes the `DataFormat` constructor private: private DataFormat(@NamedArg("ids") String... ids) and replaces it with public static DataFormat of(String ... ids) ### Problem There seems to be several issues with DataFormat API and implementation discovered during a Clipboard-related code review: 1. `static DataFormat::lookupMimeType(String)` is not thread safe: while iterating over previously registered entries in the `DATA_FORMAT_LIST` another thread might create a new instance (DataFormat L227) 2. `public DataFormat(String...)` constructor might throw an `IllegalArgumentException` if one of the given mime types is already assigned to another `DataFormat`. The origin of this requirement is unclear, but one possible issue I can see is if the application has two libraries that both attempt to create a `DataFormat` for let's say `"text/css"`. Then, depending on the timing or the exact code path, an exception will be thrown for which the library(-ies) might not be prepared. The constructor is also not thread safe. 3. To avoid a situation mentioned in bullet 2, a developer would is typically call `lookupMimeType()` to obtain an already registered instance, followed by a constructor call if such an instance has not been found. An example of such code can be seen in webkit/UIClientImpl:299 - but even then, despite that two-step process being synchronized, the code might still fail if *some other* library or the application attempts to create a new instance of DataFormat, since the constructor itself is not synchronized. 4. `DataFormat(new String[] { null })` is allowed but makes no sense! Why do we need to have the registry of previously created instances? Unclear. My theory is that the DataFormat allows to have multiple mime-types (ids) - example being `DataFormat.FILES = new DataFormat("application/x-java-file-list", "java.file-list");` - and the registry was added to prevent creation of a `DataFormat` with just one id for some reason. What should be done? - find out why we need this registry in the first place i.e. what could happen if we have multiple DataFormat instances with overlapping ids. - if the registry is needed add a new factory method, something like `DataFormat::of(String ...)` which is properly synchronized. This method will be called by the constructor to retain the backward compatibility. - deprecate (possibly for removal) `DataFormat::lookupMimeType(String)`, or keep it but have it properly synchronized ### Dangers 1. adding synchronization might lead to deadlocks if the application or library has existing code synchronized around some other object and not `DataFormat.class`. 2. removing the public constructor is a very visible, breaking change ### Alternatives We could possibly prevent the application code creating `DataFormat`s with multiple ids by - creating a `public DataFormat(String)` constructor - allowing multiple instances with the same id by removing the registry or using the registry only for `DataFormat`s with multiple ids Or, deprecate (not for removal) the `public DataFormat(@NamedArg("ids") String... ids)` constructor for backward compatibility (also allowing the issues listed above), while adding `DataHandler.of(String)` factory for those applications that want to guarantee the absence of these issues. ------------- Commit messages: - Merge branch 'master' into 8373452.data.format - junit - whitespace - javadoc - data format Changes: https://git.openjdk.org/jfx/pull/2006/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373452 Stats: 158 lines in 10 files changed: 82 ins; 35 del; 41 mod Patch: https://git.openjdk.org/jfx/pull/2006.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2006/head:pull/2006 PR: https://git.openjdk.org/jfx/pull/2006 From mstrauss at openjdk.org Tue Jan 20 21:15:46 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 21:15:46 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:58:12 GMT, Andy Goryachev wrote: > Not going away - possibly. But it does not change the fact that these properties are stored in the wrong place. Adding some sort of band-aid code to help with some use cases seems a bit wrong to me. It does not mean that we don't have the actual problem. I would say that they are stored exactly where they belong, in the object which which they are associated. From an implementation standpoint, I agree with you that they are stored in the wrong place, namely in the `Node.getProperties()` map, which is user-accessible. An attached property should not disappear because user code calls `Node.getProperties().clear()`, the storage for these properties should be opaque. This is a defect that I plan to address in a future enhancement. > > Perhaps you could describe a couple of use cases where the new API would shine, I already did: >> For example, you could decorate arbitrary model objects with context-specific state: an entity could be "valid" as it relates to a specific validator or rule, it could be "selected" in a specific context, or it could carry metadata (constraints, tags, flags) that is only meaningful for a particular framework. As far as layout constraints go, they are _not_ associated with the container. It doesn't make sense so say that the row index is a property of the grid; it's a property of an object within the grid. Similarly, it doesn't make sense to say that `HeaderBar.prefButtonHeight` is a property of the header bar; it's a property of the stage that is only relevant in relation to the header bar. > use cases where it is impossible to achieve the goal using the existing APIs. Demonstrating impossibility is an unreasonable demand. In general, formalizing attached properties adds nothing conceptually, it merely straightens out rough edges of what's already there and gives a name to convention. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3774971872 From angorya at openjdk.org Tue Jan 20 21:34:45 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 21:34:45 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 20:56:27 GMT, Michael Strau? wrote: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. Thank you for clarifications! I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container. What happens when the code moves the node with these properties to another similar container? Whose responsibility it is to clear the unrelated properties and why is this needed in the first place? If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container? This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX. But why add more weird code on top of weird code? So I am not convinced: the use case you mentioned is just too abstract, and nothing tells me that it can't be implemented using existing APIs. What is the problem you are trying to solve, apart from some unnamed "tools"? These tools can simply query the `Node.getProperties()` for these properties, given the keys are Strings, can't they? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775039635 From jhendrikx at openjdk.org Tue Jan 20 21:34:47 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 20 Jan 2026 21:34:47 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:25:42 GMT, Andy Goryachev wrote: > > JavaFX already has this concept today, but we're not using the `Property` API to model it. Layout constraints like `GridPane.columnIndex` or `HBox.margin` are implemented as static getter/setter pairs. Since they are not first-class properties, you don't get any of the nice property features (bindings, listeners, styling, etc). > > I always found this design to be weird and unnecessary - these should be the properties/constraints of the container or the layout, not something stored in the child nodes. What happens when the said child is moved from one container to another?? > > It might be just me, but I fail to see the value of this proposal. This is basically the JavaFX way to attach layout information to nodes, used by `GridPane`, `HBox`, `StackPane`, etc. In Swing this is handled differently by making layout constraints a 2nd parameter when adding a node (like `GridBagConstraints`), in FX this is done via the general `Properties` map which is much more flexible. Extending this system so they become full, observable properties, and even styleable properties is a very logical step. Making them styleable for example will allow you to move them to CSS: .button { -fx-hbox-margin: 10 10 10 10; -fx-hbox-hgrow: ALWAYS; } This is currently one of the biggest missing features when it comes to styling controls, having to go to programmatic configuration for these kinds of styling properties. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775047169 From angorya at openjdk.org Tue Jan 20 21:58:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 21:58:03 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: <29XaKfSITRbwhFcAxUrP4Hm4YSslV_mWBK6kPk3S2XM=.20ba2499-5013-48e1-8828-7d7569c7387f@github.com> On Tue, 20 Jan 2026 21:32:23 GMT, John Hendrikx wrote: >>> JavaFX already has this concept today, but we're not using the `Property` API to model it. Layout constraints like `GridPane.columnIndex` or `HBox.margin` are implemented as static getter/setter pairs. Since they are not first-class properties, you don't get any of the nice property features (bindings, listeners, styling, etc). >> >> I always found this design to be weird and unnecessary - these should be the properties/constraints of the container or the layout, not something stored in the child nodes. What happens when the said child is moved from one container to another?? >> >> It might be just me, but I fail to see the value of this proposal. > >> > JavaFX already has this concept today, but we're not using the `Property` API to model it. Layout constraints like `GridPane.columnIndex` or `HBox.margin` are implemented as static getter/setter pairs. Since they are not first-class properties, you don't get any of the nice property features (bindings, listeners, styling, etc). >> >> I always found this design to be weird and unnecessary - these should be the properties/constraints of the container or the layout, not something stored in the child nodes. What happens when the said child is moved from one container to another?? >> >> It might be just me, but I fail to see the value of this proposal. > > This is basically the JavaFX way to attach layout information to nodes, used by `GridPane`, `HBox`, `StackPane`, etc. In Swing this is handled differently by making layout constraints a 2nd parameter when adding a node (like `GridBagConstraints`), in FX this is done via the general `Properties` map which is much more flexible. Extending this system so they become full, observable properties, and even styleable properties is a very logical step. Making them styleable for example will allow you to move them to CSS: > > > .button { > -fx-hbox-margin: 10 10 10 10; > -fx-hbox-hgrow: ALWAYS; > } > > This is currently one of the biggest missing features when it comes to styling controls, having to go to programmatic configuration for these kinds of styling properties. Thank you @hjohn this example makes sense. So, if I understand it correctly, the proposal is to add two-tiered styleable properties? Are there limitations as to which attached property is legal for which node, or any attached property (including custom) can be attached to any node? I understand that CSS part is not there yet, but perhaps this PR should instead go via `HasAttachedProperties` route? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775125620 From kcr at openjdk.org Tue Jan 20 22:05:27 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 22:05:27 GMT Subject: RFR: 8373452: DataFormat threading and API issues In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:38:49 GMT, Andy Goryachev wrote: > ### Summary > > This PR makes the `DataFormat` constructor private: > > private DataFormat(@NamedArg("ids") String... ids) > > > and replaces it with > > public static DataFormat of(String ... ids) > > > ### Problem > > There seems to be several issues with DataFormat API and implementation discovered during a Clipboard-related code review: > > 1. `static DataFormat::lookupMimeType(String)` is not thread safe: while iterating over previously registered entries in the `DATA_FORMAT_LIST` another thread might create a new instance (DataFormat L227) > > 2. `public DataFormat(String...)` constructor might throw an `IllegalArgumentException` if one of the given mime types is already assigned to another `DataFormat`. The origin of this requirement is unclear, but one possible issue I can see is if the application has two libraries that both attempt to create a `DataFormat` for let's say `"text/css"`. Then, depending on the timing or the exact code path, an exception will be thrown for which the library(-ies) might not be prepared. The constructor is also not thread safe. > > 3. To avoid a situation mentioned in bullet 2, a developer would is typically call `lookupMimeType()` to obtain an already registered instance, followed by a constructor call if such an instance has not been found. An example of such code can be seen in webkit/UIClientImpl:299 - but even then, despite that two-step process being synchronized, the code might still fail if *some other* library or the application attempts to create a new instance of DataFormat, since the constructor itself is not synchronized. > > 4. `DataFormat(new String[] { null })` is allowed but makes no sense! > > Why do we need to have the registry of previously created instances? Unclear. My theory is that the DataFormat allows to have multiple mime-types (ids) - example being `DataFormat.FILES = new DataFormat("application/x-java-file-list", "java.file-list");` - and the registry was added to prevent creation of a `DataFormat` with just one id for some reason. > > What should be done? > - find out why we need this registry in the first place i.e. what could happen if we have multiple DataFormat instances with overlapping ids. > - if the registry is needed add a new factory method, something like `DataFormat::of(String ...)` which is properly synchronized. This method will be called by the constructor to retain the backward compatibility. > - deprecate (possibly for removal) `DataFormat::lookupMimeType(String)`, or keep it but have it properly synchronized > > ### Da... Removing the constructor is an incompatible change. modules/javafx.graphics/src/main/java/javafx/scene/input/DataFormat.java line 133: > 131: */ > 132: @Deprecated(since = "27") > 133: private DataFormat(@NamedArg("ids") String... ids) { This is an incompatible change. You will need to go through the usual process for such changes where it is deprecated for removal in one release and removed in a subsequent release. ------------- PR Review: https://git.openjdk.org/jfx/pull/2006#pullrequestreview-3684486211 PR Review Comment: https://git.openjdk.org/jfx/pull/2006#discussion_r2710227940 From jhendrikx at openjdk.org Tue Jan 20 22:05:54 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 20 Jan 2026 22:05:54 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 21:30:01 GMT, Andy Goryachev wrote: > Thank you for clarifications! > > I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container. What happens when the code moves the node with these properties to another similar container? Nothing happens, just like for the past 15 years. The properties can live on there, until they're needed again when the node becomes part of a layout container. > Whose responsibility it is to clear the unrelated properties and why is this needed in the first place? This falls on the user, as they're the ones setting these properties, if they care (they don't stack up, there is a fixed number of them) and leaving them alone doesn't break anything. So, there is no need to clean them at all. It's exceedingly rare that a Node is re-used in such a way that this would matter (ie. moving a Node from a HBox to a GridPane, instead of what usually happens, which is just to recreate the Node). > If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container? This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX. But why add more weird code on top of weird code? Using a hash table actually makes this worse. Reparenting or temporarily removing a node would mean you also have to move or reconstruct its constraints, or lose them entirely. With attached properties, the metadata naturally travels with the node. In practice this case is rare anyway, so it shouldn?t carry much weight in the design discussion. Swing?s choices predate modern UI frameworks, and its designers were involved in creating JavaFX, so they clearly understood the trade-offs. Since then, almost all modern UI frameworks have converged on the attached-property style, including modern web layout via CSS. FX already follows this model, which is great as it was conceived over 15 years ago. What?s weird is not that layout metadata lives on the node, but that it?s exposed only through static setters instead of real, styleable, observable properties. Continuing this design would remove some of the weirdness, not add to it. It would also allow these properties to integrate cleanly with the CSS engine, opening up an entirely new way of controlling layout, where there exists a huge gap now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775153409 From mstrauss at openjdk.org Tue Jan 20 22:08:03 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 20 Jan 2026 22:08:03 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 22:02:07 GMT, John Hendrikx wrote: >> Thank you for clarifications! >> >> I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container. What happens when the code moves the node with these properties to another similar container? Whose responsibility it is to clear the unrelated properties and why is this needed in the first place? If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container? This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX. But why add more weird code on top of weird code? >> >> So I am not convinced: the use case you mentioned is just too abstract, and nothing tells me that it can't be implemented using existing APIs. What is the problem you are trying to solve, apart from some unnamed "tools"? These tools can simply query the `Node.getProperties()` for these properties, given the keys are Strings, can't they? > >> Thank you for clarifications! >> >> I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container. What happens when the code moves the node with these properties to another similar container? > > Nothing happens, just like for the past 15 years. The properties can live on there, until they're needed again when the node becomes part of a layout container. > >> Whose responsibility it is to clear the unrelated properties and why is this needed in the first place? > > This falls on the user, as they're the ones setting these properties, if they care (they don't stack up, there is a fixed number of them) and leaving them alone doesn't break anything. So, there is no need to clean them at all. It's exceedingly rare that a Node is re-used in such a way that this would matter (ie. moving a Node from a HBox to a GridPane, instead of what usually happens, which is just to recreate the Node). > >> If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container? This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX. But why add more weird code on top of weird code? > > Using a hash table actually makes this worse. Reparenting or temporarily removing a node would mean you also have to move or reconstruct its constraints, or lose them entirely. With attached properties, the metadata naturally travels with the node. In practice this case is rare anyway, so it shouldn?t carry much weight in the design discussion. > > Swing?s choices predate modern UI frameworks, and its designers were involved in creating JavaFX, so they clearly understood the trade-offs. Since then, almost all modern UI frameworks have converged on the attached-property style, including modern web layout via CSS. > > FX already follows this model, which is great as it was conceived over 15 years ago. What?s weird is not that layout metadata lives on the node, but that it?s exposed only through static setters instead of real, styleable, observable properties. Continuing this design would remove some of the weirdness, not add to it. It would also allow these properties to integrate cleanly with the CSS engine, opening up an entirely new way of controlling layout, where there exists a huge gap now. > Thank you @hjohn this example makes sense. > > So, if I understand it correctly, the proposal is to add two-tiered styleable properties? Are there limitations as to which attached property is legal for which node, or any attached property (including custom) can be attached to any node? There can be limitations. For example, `HeaderBar.prefButtonHeight` can only be attached to `Stage`, while layout constraints can only be attached to `Node`. The restriction is indicated by the target parameter of the static accessor, for example: class HBox { public static void setMargin(Node node, Insets value); } This proposal formalizes a target-type restriction with the `AttachedProperty` interface: interface AttachedProperty { Class getTargetClass(); } If you're given a property instance, this allows you to then query the class of objects for which it can be set. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775172871 From jhendrikx at openjdk.org Tue Jan 20 22:12:10 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 20 Jan 2026 22:12:10 GMT Subject: RFR: 8375588: Enhanced property metadata In-Reply-To: <29XaKfSITRbwhFcAxUrP4Hm4YSslV_mWBK6kPk3S2XM=.20ba2499-5013-48e1-8828-7d7569c7387f@github.com> References: <29XaKfSITRbwhFcAxUrP4Hm4YSslV_mWBK6kPk3S2XM=.20ba2499-5013-48e1-8828-7d7569c7387f@github.com> Message-ID: <--PO_mMV90eMpofE2GxRsYM7ZXu6c-o4DMFwAdQUcCA=.8bff5f40-109a-42d7-a4b7-9da14177988b@github.com> On Tue, 20 Jan 2026 21:53:57 GMT, Andy Goryachev wrote: > So, if I understand it correctly, the proposal is to add two-tiered styleable properties? Are there limitations as to which attached property is legal for which node, or any attached property (including custom) can be attached to any node? I understand that CSS part is not there yet, but perhaps this PR should instead go via `HasAttachedProperties` route? It's not really two-tiered, or I am unsure what you mean by that. The properties are just coming from the container as a source, but they are still first class properties in all other respects. There aren't any limitations what a container could have as an attached property; the properties are container type specific, and other container types cannot accidentally get confused by them -- although we could perhaps share a few common property types among FX's containers; margin might be a good example (other frameworks also do this kind of sharing). So if you moved a node from GridPane to HBox, you wouldn't need to set the margin again, but may have to adjust container specific properties. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775186239 From angorya at openjdk.org Tue Jan 20 23:12:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 20 Jan 2026 23:12:03 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v2] In-Reply-To: References: Message-ID: > The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. > > Improvements include: > - syncing the toolbar with current character attributes > - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) > - paragraph format dialog, with the associated toolbar button and the main menu item > > Screenshot 2026-01-15 at 12 01 44 > > Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Merge branch 'master' into 8373936.editor - Merge branch 'master' into 8373936.editor - Merge branch 'master' into 8373936.editor - whitespace - whitespace - Merge branch '8374035.insert.styles' into 8373936.editor - 2026 - Merge branch 'master' into 8374035.insert.styles - Merge branch '8374347.paragraph.direction' into 8373936.editor - 2026 - ... and 25 more: https://git.openjdk.org/jfx/compare/f617ac7e...482176b3 ------------- Changes: https://git.openjdk.org/jfx/pull/2026/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2026&range=01 Stats: 1223 lines in 12 files changed: 797 ins; 308 del; 118 mod Patch: https://git.openjdk.org/jfx/pull/2026.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2026/head:pull/2026 PR: https://git.openjdk.org/jfx/pull/2026 From angorya at openjdk.org Wed Jan 21 00:04:30 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 00:04:30 GMT Subject: RFR: 8373452: DataFormat threading and API issues In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 22:01:58 GMT, Kevin Rushforth wrote: >> ### Summary >> >> This PR makes the `DataFormat` constructor private: >> >> private DataFormat(@NamedArg("ids") String... ids) >> >> >> and replaces it with >> >> public static DataFormat of(String ... ids) >> >> >> ### Problem >> >> There seems to be several issues with DataFormat API and implementation discovered during a Clipboard-related code review: >> >> 1. `static DataFormat::lookupMimeType(String)` is not thread safe: while iterating over previously registered entries in the `DATA_FORMAT_LIST` another thread might create a new instance (DataFormat L227) >> >> 2. `public DataFormat(String...)` constructor might throw an `IllegalArgumentException` if one of the given mime types is already assigned to another `DataFormat`. The origin of this requirement is unclear, but one possible issue I can see is if the application has two libraries that both attempt to create a `DataFormat` for let's say `"text/css"`. Then, depending on the timing or the exact code path, an exception will be thrown for which the library(-ies) might not be prepared. The constructor is also not thread safe. >> >> 3. To avoid a situation mentioned in bullet 2, a developer would is typically call `lookupMimeType()` to obtain an already registered instance, followed by a constructor call if such an instance has not been found. An example of such code can be seen in webkit/UIClientImpl:299 - but even then, despite that two-step process being synchronized, the code might still fail if *some other* library or the application attempts to create a new instance of DataFormat, since the constructor itself is not synchronized. >> >> 4. `DataFormat(new String[] { null })` is allowed but makes no sense! >> >> Why do we need to have the registry of previously created instances? Unclear. My theory is that the DataFormat allows to have multiple mime-types (ids) - example being `DataFormat.FILES = new DataFormat("application/x-java-file-list", "java.file-list");` - and the registry was added to prevent creation of a `DataFormat` with just one id for some reason. >> >> What should be done? >> - find out why we need this registry in the first place i.e. what could happen if we have multiple DataFormat instances with overlapping ids. >> - if the registry is needed add a new factory method, something like `DataFormat::of(String ...)` which is properly synchronized. This method will be called by the constructor to retain the backward compatibility. >> - deprecate (possibly for removal) `DataFormat::lookupMimeType(St... > > modules/javafx.graphics/src/main/java/javafx/scene/input/DataFormat.java line 133: > >> 131: */ >> 132: @Deprecated(since = "27") >> 133: private DataFormat(@NamedArg("ids") String... ids) { > > This is an incompatible change. You will need to go through the usual process for such changes where it is deprecated for removal in one release and removed in a subsequent release. should we also print a warning to `stderr`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2006#discussion_r2710486058 From mstrauss at openjdk.org Wed Jan 21 01:07:15 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 01:07:15 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: ReadOnlyProperty.getDeclaringClass() tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2015/files - new: https://git.openjdk.org/jfx/pull/2015/files/d38832c4..1d95a5d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=00-01 Stats: 157 lines in 1 file changed: 157 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2015.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2015/head:pull/2015 PR: https://git.openjdk.org/jfx/pull/2015 From duke at openjdk.org Wed Jan 21 03:47:49 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 03:47:49 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v2] In-Reply-To: References: Message-ID: <2DVbU0BgK7VcIdVpoQaGqLOMZbVNNbZX3L2FyEsML28=.f4733ea2-24a8-4e7f-80d9-f0ae842bdfba@github.com> > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Improve comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2044/files - new: https://git.openjdk.org/jfx/pull/2044/files/4bd4a1a1..86520bd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2044&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2044&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2044/head:pull/2044 PR: https://git.openjdk.org/jfx/pull/2044 From duke at openjdk.org Wed Jan 21 03:47:51 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 03:47:51 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 11:37:20 GMT, Christopher Schnick wrote: > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there I tested it on macOS as well now. It seems like the autofix behaviour in general does not really work in cases where you put the popup next to the dock instead of on top of it. The autofix for popups takes the dock or taskbar into consideration, but in the case of macOS with a dock that does not go from one side tothe other, there is this special case where it behaves wrongly. That is however a separate issue that affects all popups. This one is specific to combo boxes where you open it on top of the dock or the taskbar. This PR fixes the described issue for me both on Windows and macOS (excluding the general dock positioning issue). I can look into a follow-up issue for the dock positioning code, but I think that will be quite difficult. To properly fix that as well, one would have to somehow calculate the exact dock bounds and adapt the positioning based on that, which already sounds difficult. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2044#issuecomment-3775983504 From duke at openjdk.org Wed Jan 21 03:47:53 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 03:47:53 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:44:19 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 490: > >> 488: // The popup does not directly store information on whether it was autofixed >> 489: // We can determine this by looking whether it was moved upward >> 490: boolean wasAutofixed = popup.getY() < getSkinnable().localToScreen(0, 0).getY(); > > what does this mean? the popup was auto-fixed, but incorrectly? > should we change the auto-fixing code instead then? > > alternatively, is it possible that we should adjust the popup each time instead of adding the 'first' argument? When a popup is autofixed, the logic for changing the height is different. Instead of just changing the height when needed, you need to change the height and the y position to retain the original positioning relative to the combo box. Otherwise, the popup will move on the y axis relative to the combo box. On the first pass, this calculation is not needed as the previous popup height is 0. This fix only applies to the second pass in case the height changed from the first pass. That is why I added the first boolean to indicate that ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2044#discussion_r2710850071 From hmeda at openjdk.org Wed Jan 21 05:19:50 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 21 Jan 2026 05:19:50 GMT Subject: RFR: 8368572: Update WebKit to 623.1 [v2] In-Reply-To: References: Message-ID: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. Hima Bindu Meda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - resolve compilation error due to latest merge - Merge branch 'master' into webkit-623.1 - change file permissions - whitespace correction - Update webkit to v623.1 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2042/files - new: https://git.openjdk.org/jfx/pull/2042/files/90768a98..db8d26eb Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2042&range=00-01 Stats: 715 lines in 28 files changed: 620 ins; 44 del; 51 mod Patch: https://git.openjdk.org/jfx/pull/2042.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2042/head:pull/2042 PR: https://git.openjdk.org/jfx/pull/2042 From hmeda at openjdk.org Wed Jan 21 09:32:28 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 21 Jan 2026 09:32:28 GMT Subject: RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:13:55 GMT, Kevin Rushforth wrote: > @HimaBinduMeda There is a minor merge issue that will need to be fixed up following the recent integration of the changes from PR #2047 . > > To address this, do the following: > > 1. Merge in the latest jfx master. > > 2. Apply the following patch: > > > ``` > --- a/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp > +++ b/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/ComplexTextController.cpp > @@ -499,7 +499,7 @@ void ComplexTextController::ComplexTextRun::setIsNonMonotonic() > #else > for (unsigned i = 0; i < m_glyphCount; ++i) { > // Skip zero-width glyphs if needed > - if (m_font.isZeroWidthSpaceGlyph(m_glyphs[i])) > + if (m_font->isZeroWidthSpaceGlyph(m_glyphs[i])) > continue; > // Handle out of bound case > unsigned charIndex = indexAt(i); > ``` > > I've already tested it both locally, and in our CI, so I'll just run a sanity test once you update the PR. I have merged the latest jfx master and applied the patch to resolve build failure. Verified locally on mac and in our CI build. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2042#issuecomment-3777067238 From jhendrikx at openjdk.org Wed Jan 21 11:17:48 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Jan 2026 11:17:48 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 01:07:15 GMT, Michael Strau? wrote: >> Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). >> >> ### New API >> This PR includes the following API additions: >> >> 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. >> 2. The `javafx.beans.property.AttachedProperty` interface. >> 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. >> >> The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. >> >> ### Testing >> For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: >> * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. >> * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). >> * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. >> * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. >> * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. >> * An instance property does not implement `AttachedProperty`. >> * An instance property has a parameterless property getter. >> * An attached property implements `AttachedProperty`. >> * An attached property has a static single-argument property getter that accepts the target object. >> * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. >> * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. >> >> Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > ReadOnlyProperty.getDeclaringClass() tests Hm, perhaps now that the idea here has had some time to sink in, perhaps the initial version with attachedness directly specified on the `ReadOnlyProperty` interface was better (also in light of the hoops we now need to jump through in the wrappers). Unless of course you think this *is* the better solution. It seems to me that since we're already adding some weight to all the `Simple` property classes, and now additional mini-classes just to implement `AttachedProperty`, a solution where there is one or two default methods on `ReadOnlyProperty` is lighter, even if they may seem out of place (like I said, the idea needed some time to sink in, and there may be a good enough case to have this on simply **all** properties, UI related or not). Best however to see what other reviewers think. All in all, I think this is a good infrastructural change to build upon for making all static properties attached (I'm especially excited for `HBox`, `VBox` and `GridPane`), and I assume there will be follow-up PR's (where I could perhaps help) to modify these classes, as well and supporting these to be styleable by CSS. The included `HeaderBar` changes may be better done separately. Also are you sure this will work for styleable properties as well? modules/javafx.base/src/main/java/javafx/beans/property/AttachedProperty.java line 46: > 44: * Returns the class of objects to which this property can be attached. > 45: * > 46: * @return the target class If this can ever return `null` (pretty sure it can), then I think that should be documented so there is no need to guess. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyBooleanWrapper.java line 84: > 82: > 83: /** > 84: * The constructor of {@code ReadOnlyBooleanWrapper} nit: Here and in a lot of other places, missing punctuation at end of sentence of main javadoc comment. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyBooleanWrapper.java line 163: > 161: return ((AttachedProperty)ReadOnlyBooleanWrapper.this).getTargetClass(); > 162: } > 163: } This is clumsier than I had hoped. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyProperty.java line 59: > 57: String getName(); > 58: > 59: /** Should we add docs to `getBean()` as well? If I understand correctly, the declaring class can be say `HBox` for an attached property, and the bean instance would then be a child of the hbox. The documentation for `getBean` then seems outdated, or could be clarified in light of this? As it stands, one might think that `getBean().getClass() == getDeclaringClass()` (and it often is). modules/javafx.base/src/main/java/javafx/beans/property/SimpleBooleanProperty.java line 150: > 148: this.name = (name == null) ? DEFAULT_NAME : name; > 149: } > 150: } nit: I see this was already the case for existing, but just saying, I don't like the code duplication in the constructors. modules/javafx.base/src/test/java/test/util/property/PropertyMetadataVerifier.java line 172: > 170: } > 171: } else if (isSimplePropertyOrDerivedClass(propertyClass)) { > 172: fail(("%s#getDeclaringClass() must not be overridden in %s, pass %s " nit: unnecessary parentheses here modules/javafx.base/src/test/java/test/util/property/PropertyMetadataVerifier.java line 236: > 234: if (isSimplePropertyClass(propertyClass)) { > 235: return; > 236: } else { nit: no need for `else` modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 234: > 232: } > 233: > 234: class PropertyImpl extends SimpleObjectProperty implements AttachedProperty { This seems to be primarily an infrastructure PR, we should consider to leave these specific changes out. I think there are many classes that could be adjusted, for which we could create a few grouped PR's. I also noticed there is basically no users yet of the new getTargetClass method, I assume that was done deliberately as well. ------------- PR Review: https://git.openjdk.org/jfx/pull/2015#pullrequestreview-3686471870 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2711969585 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2711960784 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2712042459 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2712031904 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2712054919 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2711944565 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2711948269 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2712072320 From fkirmaier at openjdk.org Wed Jan 21 11:37:07 2026 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 21 Jan 2026 11:37:07 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v4] In-Reply-To: References: Message-ID: <6JB16KG6DkdqRpMK4yVNbpmRYlQGMyinCpKYUWgJ-w8=.b9cba316-5ed1-4616-bd8c-63777cba02a8@github.com> On Tue, 20 Jan 2026 08:41:45 GMT, Florian Kirmaier wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8375444 > Removed commented out print statements. > Fixed import order. Thank you for the two quick code reviews! I did all the small formatting changes. Please let me know, whether i should change anything else. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2040#issuecomment-3777603344 From jvos at openjdk.org Wed Jan 21 11:52:14 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Jan 2026 11:52:14 GMT Subject: [jfx17u] RFR: 8375975: Change JavaFX release version to 17.0.19 in jfx17u Message-ID: Increase javafx version in .jcheck/conf and build.properties ------------- Commit messages: - Increase JavaFX version to 17.0.19 Changes: https://git.openjdk.org/jfx17u/pull/246/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375975 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/246.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/246/head:pull/246 PR: https://git.openjdk.org/jfx17u/pull/246 From jvos at openjdk.org Wed Jan 21 11:56:53 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Jan 2026 11:56:53 GMT Subject: [jfx21u] RFR: 8375976: Change JavaFX release version to 21.0.11 in jfx21u Message-ID: Increase release version to 21.0.11 ------------- Commit messages: - Increase release version to 21.0.11 Changes: https://git.openjdk.org/jfx21u/pull/109/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375976 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/109.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/109/head:pull/109 PR: https://git.openjdk.org/jfx21u/pull/109 From duke at openjdk.org Wed Jan 21 12:15:38 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 12:15:38 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v3] In-Reply-To: References: Message-ID: > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: - Update comments - Improve positioning ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2044/files - new: https://git.openjdk.org/jfx/pull/2044/files/86520bd9..c9f33f35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2044&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2044&range=01-02 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/2044.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2044/head:pull/2044 PR: https://git.openjdk.org/jfx/pull/2044 From duke at openjdk.org Wed Jan 21 12:15:41 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 12:15:41 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v2] In-Reply-To: <2DVbU0BgK7VcIdVpoQaGqLOMZbVNNbZX3L2FyEsML28=.f4733ea2-24a8-4e7f-80d9-f0ae842bdfba@github.com> References: <2DVbU0BgK7VcIdVpoQaGqLOMZbVNNbZX3L2FyEsML28=.f4733ea2-24a8-4e7f-80d9-f0ae842bdfba@github.com> Message-ID: <1hAjpGvvZPE8XYmB3vnRN3OGytx5mWTIIPfB0pZESE8=.2c458d5d-09a4-4e3b-a7e3-db7a6241a111@github.com> On Wed, 21 Jan 2026 03:47:49 GMT, Christopher Schnick wrote: >> The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. >> >> If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. >> >> I tested this fix manually on Windows with a reproducer and it works as expected there > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment Actually, I was able to fix the dock issue as well by using a different approach ------------- PR Comment: https://git.openjdk.org/jfx/pull/2044#issuecomment-3777757620 From duke at openjdk.org Wed Jan 21 12:45:24 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 12:45:24 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v3] In-Reply-To: References: Message-ID: > This should improve the code quality of the class while preserving its original workings Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Remove unused field and not reachable code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2043/files - new: https://git.openjdk.org/jfx/pull/2043/files/898af0f9..d29fcc80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=01-02 Stats: 55 lines in 1 file changed: 0 ins; 50 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/2043.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2043/head:pull/2043 PR: https://git.openjdk.org/jfx/pull/2043 From lukasz.kostyra at oracle.com Wed Jan 21 12:48:01 2026 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Wed, 21 Jan 2026 12:48:01 +0000 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> References: <0f43b772-c555-4d2f-a522-c4cf048bfeea@xpipe.io> <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: Thanks for checking. I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine. I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :) -Lukasz From: Christopher Schnick Sent: Tuesday, 20 January 2026 16:24 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release In our main application I am getting the following error spammed in the logs: 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) 16:18:08:572 - error: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. On 20/01/2026 15:40, Lukasz Kostyra wrote: Hi Christopher, After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. Regards, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Wednesday, 10 December 2025 13:29 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release It should work fine without the property. Thanks for your help, I?ll keep searching. -Lukasz From: Christopher Schnick > Sent: Tuesday, 9 December 2025 17:10 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. Or should I still pass the property in this commit as well? On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: Hi Christopher, I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. Thanks, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Thursday, 4 December 2025 11:52 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. -Lukasz From: Christopher Schnick > Sent: Wednesday, 3 December 2025 18:53 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: Hi Christopher, I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. Thanks, -Lukasz From: Christopher Schnick Sent: Friday, 28 November 2025 13:25 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I did not encounter the vanishing issue anymore with that build, so at least it is usable. However, the font rendering issue still exists for some nodes: [cid:image001.png at 01DC8AD8.0F51F270] It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. On 28/11/2025 12:41, Lukasz Kostyra wrote: Hi Christopher, I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Monday, 17 November 2025 15:14 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it. On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. -Lukasz From: Christopher Schnick > Sent: Saturday, 15 November 2025 17:39 To: Lukasz Kostyra > Cc: OpenJFX > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release Forgot to add, there is nothing out of the ordinary printed in the verbose logs. If I find the time, I can look into compiling a debug build. But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. On 15/11/2025 17:34, Christopher Schnick wrote: Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: [cid:image002.png at 01DC8AD8.0F51F270] Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. On 13/11/2025 16:30, Lukasz Kostyra wrote: Thanks for checking. It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. Good luck! - Lukasz From: Christopher Schnick Sent: Thursday, 13 November 2025 16:11 To: Lukasz Kostyra Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. There is no exception thrown as far as I can see, so not sure what you need for debugging. For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx On 13/11/2025 14:40, Lukasz Kostyra wrote: Hello openjfx-dev, The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/ Please test this bundle and share your feedback by: - emailing openjfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. 3. It is recommended to use JDK 25 or later. 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. 5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Lukasz Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: image002.png URL: From duke at openjdk.org Wed Jan 21 12:51:45 2026 From: duke at openjdk.org (Christopher Schnick) Date: Wed, 21 Jan 2026 12:51:45 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:45:24 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused field and not reachable code Ok there seems to be a bigger issue with this class here. As @mstr2 correctly pointed out, the blend mode setter is not used. Therefore, the blend more field always has the same value. I removed all the code which is essentially unreachable due to this fact. Right now, the NGGroup class does not apply any blend more settings from the NGNode blendMode field. Whether this causes issues, I'm not sure. It should though. That is at least the current state of the code. So either this PR can keep this direction of just going for an equivalent cleanup as of right now, and there might be another follow-up ticket for the blend mode issue. Or the blend mode issue can be covered by this PR as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3777966122 From crschnick at xpipe.io Wed Jan 21 12:54:09 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Wed, 21 Jan 2026 13:54:09 +0100 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu) On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property?-Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations. You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install On 21/01/2026 13:48, Lukasz Kostyra wrote: > > Thanks for checking. > > I ran the KickstartFX build one more time, it failed but I found some > leftover global gradle.properties file which defined older JDK which > broke the build. Changing JDK to 25.0.1 everything built and works fine. > > I also found a way to build KickstartFX using custom JFX > (customJavaFxLibsPath in build.gradle) and can reproduce your font > issues locally on D3D12. I?ll report back when I solve them on my end. :) > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Tuesday, 20 January 2026 16:24 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > In our main application I am getting the following error spammed in > the logs: > > 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke > "com.sun.prism.Texture.getPixelFormat()" because "tex" is null > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) > > In kickstartfx, I still get the font rendering issues. Can you share > the problems you encountered? I tried to build it on a blank VM with > git clone, setting a JDK25 in the PATH, and running gradlew.bat run > without issues. > > On 20/01/2026 15:40, Lukasz Kostyra wrote: > > Hi Christopher, > > After Christmas break I came back to this issue with some new > patches. There were some problems I found with the clear > optimization, I just submitted > https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 > > and according to my local testing everything seems to be fine now. > > When you have a moment, could you check out the changes above and > let me know if everything works correctly in your app? > > If there are still problems I would like to find a way to build > your app and test it locally. I tried doing that earlier via > https://github.com/xpipe-io/kickstartfx > > you linked earlier but encountered some problems when building, so > I?m going to need your help or some instructions on how to build > the app. > > Regards, > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of *Lukasz Kostyra > *Sent:* Wednesday, 10 December 2025 13:29 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > It should work fine without the property. Thanks for your help, > I?ll keep searching. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Tuesday, 9 December 2025 17:10 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > I tried this commit, but the problem shows up again. I tested the > previous commit with the passed property again, and that one still > works. > > Or should I still pass the property in this commit as well? > > On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I updated the direct3d12 branch with the fix - > https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 > > . Let me know how it works and if the problem has been resolved. > > Thanks, > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of *Lukasz > Kostyra > *Sent:* Thursday, 4 December 2025 11:52 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > Thanks for checking. I filed > https://bugs.openjdk.org/browse/JDK-8373088 to track this > since this is unrelated to specifically text, will probably > get to it in a few days. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Wednesday, 3 December 2025 18:53 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > This commit fixes the problem when the property is set to > false and it shows up again if the property is not set to false > > On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I did not find the way to reproduce this locally, but I > found a problem with one of the optimizations that is in > the backend. To double check if that is in fact the issue > I pushed > https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 > > to disable the optimization (it is on by default, > disabling it fixes that specific problem on my end) and > I?d like to double-check if this is the correct lead. > > When you have a moment, could you build JFX with that > change and run your app with > ?-Dprism.d3d12.clearOpts=false? added to the command line? > > If the problem persists with prism.d3d12.clearOpts set to > false I would need some more information on how these > labels are rendered to track this down. > > Thanks, > > -Lukasz > > *From:*Christopher Schnick > > *Sent:* Friday, 28 November 2025 13:25 > *To:* Lukasz Kostyra > > *Cc:* OpenJFX > > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA > release > > I did not encounter the vanishing issue anymore with that > build, so at least it is usable. > > However, the font rendering issue still exists for some nodes: > > It is not deterministic, meaning that if I just scroll the > scrollpane forward and back, the same text might get > rendered correctly. > > Also, did you see the performance results I posted for my > AMD system? Performance was quite bad there, so this is > not in a stage where I can test this in production a bit. > > On 28/11/2025 12:41, Lukasz Kostyra wrote: > > Hi Christopher, > > I just pushed a fix for JDK-8371995 onto direct3d12 > branch in the sandbox - > https://github.com/openjdk/jfx-sandbox/tree/direct3d12 > > . If you find a moment, could you build JFX from that > branch and check if your app works correctly? > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of > *Lukasz Kostyra > *Sent:* Monday, 17 November 2025 15:14 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > I might?ve found the problem, there is an assertion > that triggers when multiple text objects using > different fonts are drawn. It could be related (AFAIK > Label controls will eventually end up at the same text > rendering routines as Text nodes). Assertions are > compiled out on Release for performance, so there is a > chance it would corrupt the rendering without anything > meaningful shown on screen. > > To track this I just filed > https://bugs.openjdk.org/browse/JDK-8371995 . I will > check it and let you know when I fix it. > > On your side It might still be handy to build JFX in > DebugNative, to confirm if the triggered assertion is > the same and to later confirm if the fix is working > for you too. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Saturday, 15 November 2025 17:39 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* Re: [External] : Re: JavaFX Direct3D 12 - > Second EA release > > Forgot to add, there is nothing out of the ordinary > printed in the verbose logs. > > If I find the time, I can look into compiling a debug > build. > > But the problem should be reproducible somehow when > just automatically creating a lot of labels with > random styles, sizes, and text. Some of them should > break as they did for me. > > On 15/11/2025 17:34, Christopher Schnick wrote: > > Ok, so I had more time to debug it. The one weird > thing I observed when it was working was that some > labels have corrupted text rendering: > > > Not all of them, most are fine. There are no > differences in terms of style classes etc. between > the labels. When scrolling, the rendering > sometimes switches between this corrupted and > normal state after some delay. > > After a while I also figured out that text > rendering is responsible for the issue of the > nodes vanishing: Certain label contents broke the > renderer. For example, in my application, the > string "Password manager" when assigned to a label > broke it and nothing was rendered anymore. I tried > to find an easy reproducer but was not able to. > It's probably very dependent on all the different > style classes that influence the text shape/size/etc. > > On 13/11/2025 16:30, Lukasz Kostyra wrote: > > Thanks for checking. > > It is very possible the D3D12 runtime did not > like something, could be related to your > specific hardware. D3D12 by now has many > extensions which differ depending on hardware > and can lift certain restrictions - we already > internally had a case where one GPU had some > restriction that was not enforced on another > GPU and we had to accommodate that. > > The first step would be to try running D3D12 > with ?-Dprism.verbose=true > -Dprism.debug=true?. These should print > additional logs that might have some extra > information. > > If there?s nothing useful there, next step > would be to build JavaFX with > -PCONF=DebugNative - this will compile shaders > in Debug, add assertions and debug logs to the > backend - and then run your app with D3D12 > debug layers and GPU debugging enabled by > adding ?-Dprsim.d3d12.debugLayers=true > -Dprism.d3d12.gpuDebug=true?. Those will slow > down the app significantly, but will also tell > D3D12 to run additional API use and GPU use > checks. > > If the problem happens during a render loop > and debug layers catch it, there is a chance > it will cascade into other errors and spam the > console output - you can tell D3D12 debug > layers to trigger an assertion on first > encountered error with > ?-Dprism.d3d12.breakOnError=true?. > > I am running out of time today to check this > myself, but if you find something let me know > - I?ll try to reproduce the problem myself and > we?ll see where we go from there. > > Good luck! > > - Lukasz > > *From:*Christopher Schnick > > *Sent:* Thursday, 13 November 2025 16:11 > *To:* Lukasz Kostyra > > > *Cc:* openjfx-dev at openjdk.org > *Subject:* [External] : Re: JavaFX Direct3D 12 > - Second EA release > > I just tried to run a project with provided > jmods and at some point, certain nodes are > just not rendered anymore and the window > contents vanish. But they render for a short > period of time. > > There is no exception thrown as far as I can > see, so not sure what you need for debugging. > > For testing, this is the built application > with the d3d12 jmods that you can use to > attempt to reproduce the problem: > https://we.tl/t-DJuX0BeqXm > > . It is built from these sources: > https://github.com/xpipe-io/kickstartfx > > > On 13/11/2025 14:40, Lukasz Kostyra wrote: > > Hello openjfx-dev, > > The second Early Access(EA) build of > JavaFX with the Windows Direct3D 12 > rendering pipeline is now available at: > https://jdk.java.net/javafxdirect3d12/ > > > Please test this bundle and share your > feedback by: > > - emailing openjfx-dev at openjdk.java.net or > > - reporting issues via > JBS[https://bugs.openjdk.org/] or at > https://bugreport.java.com > > > This is the second EA release. The backend > is feature-complete and went through a > first optimization pass, but it still > requires some more testing on more > hardware variants before we can consider > it complete. As such, with this release we > also would like to call for help with > performance testing the backend (more > details on that will be sent in a separate > email thread). > > Known issues and pending tasks are > captured on JBS and can be accessed using > the filter provided on the Direct3D 12 EA > page > [https://jdk.java.net/javafxdirect3d12/ > ]. > Before reporting a new bug, please review > the existing issues to avoid duplicates. > > Important Notes: > > 1. This is a Windows-specific feature, so > only a Windows-specific bundle is provided. > > 2. The default rendering pipeline is set > to d3d12. Use "-Dprism.order=d3d" or > "-Dprism.order=sw" to select one of the > other pipelines for comparison testing. > > 3. It is recommended to use JDK 25 or later. > > 4. At this stage D3D12 backend is > feature-complete and went through the > first phase of optimization. It is worth > noting that, while generally we noticed > performance improvements, it might not be > on par with D3D backend on every machine > combo? - we already noted performance > being worse on recent NVidia discrete GPUs > [https://bugs.openjdk.org/browse/JDK-8370486] > and are looking for solutions. > > 5. Issue behavior may vary across > different hardware, so please provide > detailed information, such as the output > of "java -Dprism.verbose=true" or used > hardware, when reporting or discussing issues. > > 6. Refer: Run HelloWorld using JavaFX SDK > [https://openjfx.io/openjfx-docs/#install-javafx > ] > > We look forward to your feedback. > > Regards, > > Lukasz > > Confidential- Oracle Internal > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: not available URL: From kcr at openjdk.org Wed Jan 21 12:56:51 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 12:56:51 GMT Subject: RFR: 8368572: Update WebKit to 623.1 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 05:19:50 GMT, Hima Bindu Meda wrote: >> This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. > > Hima Bindu Meda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - resolve compilation error due to latest merge > - Merge branch 'master' into webkit-623.1 > - change file permissions > - whitespace correction > - Update webkit to v623.1 All good. I confirm that that the only change you made since @tiainen and @johanvos approved this PR is the one-line change I mentioned above that was needed to fix the merge issue after merging the latest master. As such, I this can go in with a single re-review (by me). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2042#pullrequestreview-3687098412 From mhanl at openjdk.org Wed Jan 21 12:56:56 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 21 Jan 2026 12:56:56 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> <8AJAMdDuJ03snOo-6TrBhQSNwJ8TEk-OTX9ut5Jh6C0=.516cb3d0-30bd-4490-9a39-bc846c8d2210@github.com> Message-ID: On Thu, 15 Jan 2026 22:36:31 GMT, John Hendrikx wrote: > 1. Pulse starts > 2. Pre-layout listeners called > > * View controls add/remove children, call `updateItem` based on their current size > > * `updateItem` can do whatever it wants, including modifying styles, adding/removing children, user code need not worry about layout semantics > 3. CSS pass > > LAYOUT STARTS -- refrain from doing "more" work besides positioning/sizing > > 4. Sizes get computed (by `resizeRootToPreferredSize`) down to leafs > 5. Layout methods are called (according to dirty status) down to leafs > > LAYOUT ENDS > > 6. Either during layout or in a post-layout listener, the View class discovers it did not have enough cells, it asks for a new layout > 7. After post layout listeners have run, check if another layout is needed immediately, go to step 2 (unless limit exceeded) > 8. Pulse ends > > In this way we can prevent unnecessary layouts, and also prevent doing dangerous things during layout. Could we streamline this process with e.g. a new protected method (initially empty / delegating to `skinBase`) that is called (instead of setting pre-layout listeners everywhere). Something like `prelayout()`. We then can start shifting update logic there for `Controls`, together as an Umbrella Task? Probably need to discuss this first in the mailing list, but I agree this would be a nice idea. When doing, we should also document that, maybe in `docs` folder like the jdk has (was already discussed at one point in the mailing list at one point, so we may should just start). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3777998337 From jpereda at openjdk.org Wed Jan 21 13:15:16 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 21 Jan 2026 13:15:16 GMT Subject: [jfx21u] RFR: 8375976: Change JavaFX release version to 21.0.11 in jfx21u In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:49:55 GMT, Johan Vos wrote: > Increase release version to 21.0.11 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/109#pullrequestreview-3687181611 From jpereda at openjdk.org Wed Jan 21 13:17:50 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Wed, 21 Jan 2026 13:17:50 GMT Subject: [jfx17u] RFR: 8375975: Change JavaFX release version to 17.0.19 in jfx17u In-Reply-To: References: Message-ID: <4PgpYBxdoQDjIkXQWba4nx-9gGK6y9rc3gqcXESIUlk=.22a10cde-a451-4e8f-8adf-1c5ec6aaa9fd@github.com> On Wed, 21 Jan 2026 11:47:27 GMT, Johan Vos wrote: > Increase javafx version in .jcheck/conf and build.properties Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/246#pullrequestreview-3687194681 From hmeda at openjdk.org Wed Jan 21 13:19:27 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Wed, 21 Jan 2026 13:19:27 GMT Subject: Integrated: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: <8vpzgbgQlOt4BjTqyMxm_K4RtZD4qaceqZx0eid6rxs=.720e6140-10dd-49b9-9aff-1da3fee74e20@github.com> On Fri, 16 Jan 2026 06:58:40 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v623.1. Verified build and sanity on Mac, Linux and Windows platforms. No issue seen. This pull request has now been integrated. Changeset: 422d3a95 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/422d3a954d531c9cca32b1401b5937b05b1b07fa Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod 8368572: Update WebKit to 623.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, sykora, jvos ------------- PR: https://git.openjdk.org/jfx/pull/2042 From jvos at openjdk.org Wed Jan 21 13:49:29 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Jan 2026 13:49:29 GMT Subject: [jfx17u] Integrated: 8375975: Change JavaFX release version to 17.0.19 in jfx17u In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:47:27 GMT, Johan Vos wrote: > Increase javafx version in .jcheck/conf and build.properties This pull request has now been integrated. Changeset: 4f5e2c64 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/4f5e2c64b153199fab69072d33c7b3ca50a61745 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8375975: Change JavaFX release version to 17.0.19 in jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/246 From jvos at openjdk.org Wed Jan 21 13:52:03 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Jan 2026 13:52:03 GMT Subject: [jfx21u] Integrated: 8375976: Change JavaFX release version to 21.0.11 in jfx21u In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 11:49:55 GMT, Johan Vos wrote: > Increase release version to 21.0.11 This pull request has now been integrated. Changeset: f03d221b Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/f03d221ba11eaba91fff060b9cea98ab1b03d473 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8375976: Change JavaFX release version to 21.0.11 in jfx21u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx21u/pull/109 From jhendrikx at openjdk.org Wed Jan 21 15:09:32 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Jan 2026 15:09:32 GMT Subject: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4] In-Reply-To: References: <1eStePinnKkNY73pg5Y04u1WTUf56mhVLbMUhhvd6jY=.fececb1b-1023-428e-90ed-a9af23c94b20@github.com> <8AJAMdDuJ03snOo-6TrBhQSNwJ8TEk-OTX9ut5Jh6C0=.516cb3d0-30bd-4490-9a39-bc846c8d2210@github.com> Message-ID: On Wed, 21 Jan 2026 12:54:51 GMT, Marius Hanl wrote: > > 1. Pulse starts > > 2. Pre-layout listeners called > > > > * View controls add/remove children, call `updateItem` based on their current size > > > > * `updateItem` can do whatever it wants, including modifying styles, adding/removing children, user code need not worry about layout semantics > > 3. CSS pass > > > > LAYOUT STARTS -- refrain from doing "more" work besides positioning/sizing > > > > 4. Sizes get computed (by `resizeRootToPreferredSize`) down to leafs > > 5. Layout methods are called (according to dirty status) down to leafs > > > > LAYOUT ENDS > > > > 6. Either during layout or in a post-layout listener, the View class discovers it did not have enough cells, it asks for a new layout > > 7. After post layout listeners have run, check if another layout is needed immediately, go to step 2 (unless limit exceeded) > > 8. Pulse ends > > > > In this way we can prevent unnecessary layouts, and also prevent doing dangerous things during layout. > > Could we streamline this process with e.g. a new protected method (initially empty / delegating to `skinBase`) that is called (instead of setting pre-layout listeners everywhere). Something like `prelayout()`. We then can start shifting update logic there for `Controls`, together as an Umbrella Task? I'm not sure having a `prelayout` method would be better. If we'd have to call it on the whole hierarchy (cascading down similar to `layout`) that could be a lot of calls. If it would be limited to only `NEEDS_LAYOUT` nodes, then `prelayout` isn't quite equivalent (but perhaps sufficient). I only expect the more complicated controls to need a pre-layout listener (the View classes). Listeners are reasonably efficient (and targetted), they only suffer from one problem: removal can be slow if the amount of listeners on a single target is large (but IMHO that's a solvable problem). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3778625700 From mfox at openjdk.org Wed Jan 21 16:09:10 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 21 Jan 2026 16:09:10 GMT Subject: [jfx25u] RFR: 8367045: [Linux] Dead keys not working Message-ID: Hi all, This pull request contains a backport of commit [d5e817d6](https://github.com/openjdk/jfx/commit/d5e817d6e4f28bb1e14292f17f7fe95f5d001487) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Martin Fox on 4 Oct 2025 and was reviewed by Lukasz Kostyra and Thiago Milczarek Sayao. Thanks! ------------- Commit messages: - Backport d5e817d6e4f28bb1e14292f17f7fe95f5d001487 Changes: https://git.openjdk.org/jfx25u/pull/45/files Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=45&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367045 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx25u/pull/45.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/45/head:pull/45 PR: https://git.openjdk.org/jfx25u/pull/45 From angorya at openjdk.org Wed Jan 21 16:52:13 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 16:52:13 GMT Subject: RFR: 8375444: MenuButton - textTruncated Property is always false [v4] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 08:41:45 GMT, Florian Kirmaier wrote: >> For MenuButton and SplitMenuButton the textTruncated Property is always false - but the text is correctly rendered truncated if it is to long. >> >> This PR fixes it, by extending the logic in LabeledImpl - to always forward this property. >> I've also extended the existing tests for the truncated property. >> >> It would be great, to get some feedback on how i fixes the bug. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8375444 > Removed commented out print statements. > Fixed import order. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2040#pullrequestreview-3688313939 From angorya at openjdk.org Wed Jan 21 17:48:27 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 17:48:27 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 01:07:15 GMT, Michael Strau? wrote: >> Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). >> >> ### New API >> This PR includes the following API additions: >> >> 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. >> 2. The `javafx.beans.property.AttachedProperty` interface. >> 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. >> >> The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. >> >> ### Testing >> For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: >> * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. >> * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). >> * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. >> * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. >> * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. >> * An instance property does not implement `AttachedProperty`. >> * An instance property has a parameterless property getter. >> * An attached property implements `AttachedProperty`. >> * An attached property has a static single-argument property getter that accepts the target object. >> * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. >> * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. >> >> Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > ReadOnlyProperty.getDeclaringClass() tests two-tiered: I meant one set of normally declared properties, the other set of properties that have a meaning only in the context of some layout container (and they must be cleared when the node is moved to another container). What do you think of Set props = AttachedProperty.from(node); without the Node having to implement `HasAttachedProperties` interface? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780038047 PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780053208 From angorya at openjdk.org Wed Jan 21 18:00:37 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 18:00:37 GMT Subject: RFR: 8373452: DataFormat threading and API issues [v2] In-Reply-To: References: Message-ID: > ### Summary > > This PR makes the `DataFormat` constructor private: > > private DataFormat(@NamedArg("ids") String... ids) > > > and replaces it with > > public static DataFormat of(String ... ids) > > > ### Problem > > There seems to be several issues with DataFormat API and implementation discovered during a Clipboard-related code review: > > 1. `static DataFormat::lookupMimeType(String)` is not thread safe: while iterating over previously registered entries in the `DATA_FORMAT_LIST` another thread might create a new instance (DataFormat L227) > > 2. `public DataFormat(String...)` constructor might throw an `IllegalArgumentException` if one of the given mime types is already assigned to another `DataFormat`. The origin of this requirement is unclear, but one possible issue I can see is if the application has two libraries that both attempt to create a `DataFormat` for let's say `"text/css"`. Then, depending on the timing or the exact code path, an exception will be thrown for which the library(-ies) might not be prepared. The constructor is also not thread safe. > > 3. To avoid a situation mentioned in bullet 2, a developer would is typically call `lookupMimeType()` to obtain an already registered instance, followed by a constructor call if such an instance has not been found. An example of such code can be seen in webkit/UIClientImpl:299 - but even then, despite that two-step process being synchronized, the code might still fail if *some other* library or the application attempts to create a new instance of DataFormat, since the constructor itself is not synchronized. > > 4. `DataFormat(new String[] { null })` is allowed but makes no sense! > > Why do we need to have the registry of previously created instances? Unclear. My theory is that the DataFormat allows to have multiple mime-types (ids) - example being `DataFormat.FILES = new DataFormat("application/x-java-file-list", "java.file-list");` - and the registry was added to prevent creation of a `DataFormat` with just one id for some reason. > > What should be done? > - find out why we need this registry in the first place i.e. what could happen if we have multiple DataFormat instances with overlapping ids. > - if the registry is needed add a new factory method, something like `DataFormat::of(String ...)` which is properly synchronized. This method will be called by the constructor to retain the backward compatibility. > - deprecate (possibly for removal) `DataFormat::lookupMimeType(String)`, or keep it but have it properly synchronized > > ### Da... 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 seven additional commits since the last revision: - 2026 - Merge branch 'master' into 8373452.data.format - Merge branch 'master' into 8373452.data.format - junit - whitespace - javadoc - data format ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2006/files - new: https://git.openjdk.org/jfx/pull/2006/files/f8a5552a..77ae53ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2006&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2006&range=00-01 Stats: 505673 lines in 9001 files changed: 253929 ins; 188948 del; 62796 mod Patch: https://git.openjdk.org/jfx/pull/2006.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2006/head:pull/2006 PR: https://git.openjdk.org/jfx/pull/2006 From angorya at openjdk.org Wed Jan 21 18:00:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 18:00:39 GMT Subject: RFR: 8373452: DataFormat threading and API issues [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 00:01:49 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/input/DataFormat.java line 133: >> >>> 131: */ >>> 132: @Deprecated(since = "27") >>> 133: private DataFormat(@NamedArg("ids") String... ids) { >> >> This is an incompatible change. You will need to go through the usual process for such changes where it is deprecated for removal in one release and removed in a subsequent release. > > should we also print a warning to `stderr`? resolved offline: no, since stderr will likely be noticed by the user rather than the developer. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2006#discussion_r2713710309 From kcr at openjdk.org Wed Jan 21 19:05:58 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 19:05:58 GMT Subject: [jfx26u] RFR: 8376022: Change JavaFX release version to 26.0.1 in jfx26u Message-ID: Updates for the beginning of the 26.0.1 release. ------------- Commit messages: - 8376022: Change JavaFX release version to 26.0.1 in jfx26u Changes: https://git.openjdk.org/jfx26u/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376022 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx26u/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx26u/pull/1 From jhendrikx at openjdk.org Wed Jan 21 19:24:18 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Jan 2026 19:24:18 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: <3IQmTY8VrgJyCHY3ZpMfeoA8NnZGfpnTyTCE1QLki1Q=.7e0fa005-917b-48c3-8ba7-65657dfa9785@github.com> On Wed, 21 Jan 2026 17:43:47 GMT, Andy Goryachev wrote: > two-tiered: I meant one set of normally declared properties, the other set of properties that have a meaning only in the context of some layout container (and they must be cleared when the node is moved to another container). I think the need for clearing is a bit overblown; currently when you do `HBox.setMargin(node, margin)` nobody is clearing this either when the node is moved, so I don't see this as an urgent requirement now. Clearing is possible, but it is a user task: `HBox.setMargin(node, null)`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780725721 From angorya at openjdk.org Wed Jan 21 19:24:19 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 19:24:19 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: <3IQmTY8VrgJyCHY3ZpMfeoA8NnZGfpnTyTCE1QLki1Q=.7e0fa005-917b-48c3-8ba7-65657dfa9785@github.com> References: <3IQmTY8VrgJyCHY3ZpMfeoA8NnZGfpnTyTCE1QLki1Q=.7e0fa005-917b-48c3-8ba7-65657dfa9785@github.com> Message-ID: <0I--RQ4vOdpjRpfMIwNTodSWNTch3KU-_OcfB7XJJEk=.a00f5db4-c7c0-4ff4-8c65-c194292aebdd@github.com> On Wed, 21 Jan 2026 19:17:58 GMT, John Hendrikx wrote: > the need for clearing is a bit overblown; I agree; my point is that the property belongs in the container, not the child node. I know - grandfathered, nothing we can do at this point. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780737832 From jhendrikx at openjdk.org Wed Jan 21 19:31:48 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Jan 2026 19:31:48 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: <0I--RQ4vOdpjRpfMIwNTodSWNTch3KU-_OcfB7XJJEk=.a00f5db4-c7c0-4ff4-8c65-c194292aebdd@github.com> References: <3IQmTY8VrgJyCHY3ZpMfeoA8NnZGfpnTyTCE1QLki1Q=.7e0fa005-917b-48c3-8ba7-65657dfa9785@github.com> <0I--RQ4vOdpjRpfMIwNTodSWNTch3KU-_OcfB7XJJEk=.a00f5db4-c7c0-4ff4-8c65-c194292aebdd@github.com> Message-ID: On Wed, 21 Jan 2026 19:21:08 GMT, Andy Goryachev wrote: > > the need for clearing is a bit overblown; > > I agree; my point is that the property belongs in the container, not the child node. I know - grandfathered, nothing we can do at this point. The current state of affairs in FX matches much closer with most frameworks created after Swing, having the attached properties be part of the child, not the container. In other words, FX is the more modern and more flexible design here, and I'm sure the designers also drew upon lessons learned in this regard from Swing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780768238 From kcr at openjdk.org Wed Jan 21 19:31:57 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 19:31:57 GMT Subject: [jfx26u] RFR: 8376022: Change JavaFX release version to 26.0.1 in jfx26u In-Reply-To: References: Message-ID: <7nosxB0RAeBlk1rxdryHKp4Nmv7F2rGEwav3p6_M7qE=.21a38dc2-ee9e-4705-9c8a-db252ff143f3@github.com> On Wed, 21 Jan 2026 18:47:57 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 26.0.1 release. Reviewers: @arapte or @johanvos @johanvos Can you do the maintainer approval when you get a chance? ------------- PR Comment: https://git.openjdk.org/jfx26u/pull/1#issuecomment-3780767496 From jhendrikx at openjdk.org Wed Jan 21 19:38:22 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 21 Jan 2026 19:38:22 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: <3nFECseys_58L7VYVhFucZXmG8UlkrbKEV0rLf7M2ZA=.59ef9683-7ba5-4b9a-9e73-bc7f479d95e0@github.com> On Wed, 21 Jan 2026 01:07:15 GMT, Michael Strau? wrote: >> Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). >> >> ### New API >> This PR includes the following API additions: >> >> 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. >> 2. The `javafx.beans.property.AttachedProperty` interface. >> 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. >> >> The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. >> >> ### Testing >> For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: >> * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. >> * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). >> * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. >> * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. >> * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. >> * An instance property does not implement `AttachedProperty`. >> * An instance property has a parameterless property getter. >> * An attached property implements `AttachedProperty`. >> * An attached property has a static single-argument property getter that accepts the target object. >> * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. >> * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. >> >> Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > ReadOnlyProperty.getDeclaringClass() tests Perhaps it could help to think of attached properties as simple configuration on the node, not as temporary state owned by a container. You may not know which container a node will end up in, but you can still set things like a margin, or tell it to grow if it?s placed in a VBox. You might do the same for other container types it could live in. When the node is actually added to a parent, that parent just reads the properties it understands and ignores the rest. >From that point of view, it?s hard to justify why a container should remove properties it didn?t set. Auto-removal makes moving a node between parents lossy and surprising, because you lose configuration that was intentionally added. A simpler rule is: keep attached properties on the node, let containers use what applies to them, and only remove a property if the code that added it explicitly does so. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780792738 From jvos at openjdk.org Wed Jan 21 19:42:38 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 21 Jan 2026 19:42:38 GMT Subject: [jfx26u] RFR: 8376022: Change JavaFX release version to 26.0.1 in jfx26u In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:47:57 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 26.0.1 release. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx26u/pull/1#pullrequestreview-3689058523 From angorya at openjdk.org Wed Jan 21 19:43:54 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 19:43:54 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v3] In-Reply-To: References: Message-ID: > The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. > > Improvements include: > - syncing the toolbar with current character attributes > - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) > - paragraph format dialog, with the associated toolbar button and the main menu item > > Screenshot 2026-01-15 at 12 01 44 > > Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: actions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2026/files - new: https://git.openjdk.org/jfx/pull/2026/files/482176b3..3a4f499c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2026&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2026&range=01-02 Stats: 172 lines in 3 files changed: 82 ins; 74 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/2026.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2026/head:pull/2026 PR: https://git.openjdk.org/jfx/pull/2026 From angorya at openjdk.org Wed Jan 21 19:49:27 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 19:49:27 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v4] In-Reply-To: References: Message-ID: > The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. > > Improvements include: > - syncing the toolbar with current character attributes > - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) > - paragraph format dialog, with the associated toolbar button and the main menu item > > Screenshot 2026-01-15 at 12 01 44 > > Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into 8373936.editor - actions - Merge branch 'master' into 8373936.editor - Merge branch 'master' into 8373936.editor - Merge branch 'master' into 8373936.editor - whitespace - whitespace - Merge branch '8374035.insert.styles' into 8373936.editor - 2026 - Merge branch 'master' into 8374035.insert.styles - ... and 27 more: https://git.openjdk.org/jfx/compare/422d3a95...df6dbb17 ------------- Changes: https://git.openjdk.org/jfx/pull/2026/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2026&range=03 Stats: 1323 lines in 12 files changed: 846 ins; 349 del; 128 mod Patch: https://git.openjdk.org/jfx/pull/2026.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2026/head:pull/2026 PR: https://git.openjdk.org/jfx/pull/2026 From mstrauss at openjdk.org Wed Jan 21 20:03:37 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:03:37 GMT Subject: RFR: 8375588: Enhanced property metadata [v3] In-Reply-To: References: Message-ID: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2015/files - new: https://git.openjdk.org/jfx/pull/2015/files/1d95a5d3..1c624728 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=01-02 Stats: 420 lines in 23 files changed: 26 ins; 152 del; 242 mod Patch: https://git.openjdk.org/jfx/pull/2015.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2015/head:pull/2015 PR: https://git.openjdk.org/jfx/pull/2015 From mstrauss at openjdk.org Wed Jan 21 20:03:45 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:03:45 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:37:12 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> ReadOnlyProperty.getDeclaringClass() tests > > modules/javafx.base/src/main/java/javafx/beans/property/AttachedProperty.java line 46: > >> 44: * Returns the class of objects to which this property can be attached. >> 45: * >> 46: * @return the target class > > If this can ever return `null` (pretty sure it can), then I think that should be documented so there is no need to guess. It never returns `null`, as an attached property must have a target class. I mean it can return `null`, but that would be an implementation bug. > modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyBooleanWrapper.java line 163: > >> 161: return ((AttachedProperty)ReadOnlyBooleanWrapper.this).getTargetClass(); >> 162: } >> 163: } > > This is clumsier than I had hoped. I think it's okay as it's a very localized implementation detail. You'll probably forget that it even exists very soon and move on. > modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyProperty.java line 59: > >> 57: String getName(); >> 58: >> 59: /** > > Should we add docs to `getBean()` as well? > > If I understand correctly, the declaring class can be say `HBox` for an attached property, and the bean instance would then be a child of the hbox. The documentation for `getBean` then seems outdated, or could be clarified in light of this? > > As it stands, one might think that `getBean().getClass() == getDeclaringClass()` (and it often is). `getBean().getClass() == getDeclaringClass()` is only true if the property is declared in the most derived class. For most JavaFX properties, this would not be the case. In any case, I've updated the documentation a bit. > modules/javafx.base/src/main/java/javafx/beans/property/SimpleBooleanProperty.java line 150: > >> 148: this.name = (name == null) ? DEFAULT_NAME : name; >> 149: } >> 150: } > > nit: I see this was already the case for existing, but just saying, I don't like the code duplication in the constructors. I've changed to telescoping constructor invocation where possible. > modules/javafx.base/src/test/java/test/util/property/PropertyMetadataVerifier.java line 172: > >> 170: } >> 171: } else if (isSimplePropertyOrDerivedClass(propertyClass)) { >> 172: fail(("%s#getDeclaringClass() must not be overridden in %s, pass %s " > > nit: unnecessary parentheses here They are not unnecessary, they group the string concatenation on which the `formatted()` method is called. > modules/javafx.graphics/src/main/java/javafx/scene/layout/HeaderBar.java line 234: > >> 232: } >> 233: >> 234: class PropertyImpl extends SimpleObjectProperty implements AttachedProperty { > > This seems to be primarily an infrastructure PR, we should consider to leave these specific changes out. I think there are many classes that could be adjusted, for which we could create a few grouped PR's. > > I also noticed there is basically no users yet of the new getTargetClass method, I assume that was done deliberately as well. I included this as a small demonstration for an attached property implementation. I don't think that there will be users of `getTargetClass()` in the JavaFX framework, at least at the moment (it didn't exist before, so why would there be users). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714106046 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714115188 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714108925 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714116347 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714103282 PR Review Comment: https://git.openjdk.org/jfx/pull/2015#discussion_r2714122151 From kcr at openjdk.org Wed Jan 21 20:04:07 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 20:04:07 GMT Subject: [jfx26u] Integrated: 8376022: Change JavaFX release version to 26.0.1 in jfx26u In-Reply-To: References: Message-ID: <5JO3oQEUf6TF4bkWZtbKUDye7EQTj6yXsxpfhFf8kFY=.ac57e6dd-2cb4-42bb-8e01-f3f7c00d9c0f@github.com> On Wed, 21 Jan 2026 18:47:57 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 26.0.1 release. This pull request has now been integrated. Changeset: 8ef2629c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx26u/commit/8ef2629c1e3862e9f23fc94ea279018e0635bf9e Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8376022: Change JavaFX release version to 26.0.1 in jfx26u Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx26u/pull/1 From kcr at openjdk.org Wed Jan 21 20:11:00 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 20:11:00 GMT Subject: [jfx26u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Message-ID: This is a copy of the jfx25u README and CONTRIBUTING docs, changing 25 to 26. ------------- Commit messages: - Merge branch 'master' into 8304008-readme - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Changes: https://git.openjdk.org/jfx26u/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=2&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304008 Stats: 271 lines in 2 files changed: 1 ins; 258 del; 12 mod Patch: https://git.openjdk.org/jfx26u/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx26u/pull/2 From kcr at openjdk.org Wed Jan 21 20:11:01 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 21 Jan 2026 20:11:01 GMT Subject: [jfx26u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:38:26 GMT, Kevin Rushforth wrote: > This is a copy of the jfx25u README and CONTRIBUTING docs, changing 25 to 26. Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx26u/pull/2#issuecomment-3780902530 From mstrauss at openjdk.org Wed Jan 21 20:13:36 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:13:36 GMT Subject: RFR: 8375588: Enhanced property metadata [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:03:37 GMT, Michael Strau? wrote: >> Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). >> >> ### New API >> This PR includes the following API additions: >> >> 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. >> 2. The `javafx.beans.property.AttachedProperty` interface. >> 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. >> >> The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. >> >> ### Testing >> For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: >> * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. >> * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). >> * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. >> * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. >> * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. >> * An instance property does not implement `AttachedProperty`. >> * An instance property has a parameterless property getter. >> * An attached property implements `AttachedProperty`. >> * An attached property has a static single-argument property getter that accepts the target object. >> * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. >> * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. >> >> Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > review changes > Hm, perhaps now that the idea here has had some time to sink in, perhaps the initial version with attachedness directly specified on the `ReadOnlyProperty` interface was better (also in light of the hoops we now need to jump through in the wrappers). Unless of course you think this _is_ the better solution. I think it is the better solution, as it also provides a place for the `getTargetClass()` API. > It seems to me that since we're already adding some weight to all the `Simple` property classes, and now additional mini-classes just to implement `AttachedProperty`, a solution where there is one or two default methods on `ReadOnlyProperty` is lighter, even if they may seem out of place (like I said, the idea needed some time to sink in, and there may be a good enough case to have this on simply **all** properties, UI related or not). We're not adding weight to _all_ simple property classes. With some sensible assumptions (memory alignment is not guaranteed, the VM is free to do anything it wants), the following classes will grow from 40 to 48 bytes: `SimpleFloatProperty` `SimpleIntegerProperty` `SimpleObjectProperty` `SimpleStringProperty` The following classes have enough unused space in their layout to accomodate the new field: `SimpleBooleanProperty` (40) `SimpleDoubleProperty` (48) `SimpleLongProperty` (48) `SimpleListProperty` (56) `SimpleMapProperty` (56) `SimpleSetProperty` (56) > The included `HeaderBar` changes may be better done separately. Also are you sure this will work for styleable properties as well? I don't see why it wouldn't. This PR doesn't add much functionality in any case. Making this work for styleable properties will require a fair bit of additional work, something along the lines of what you've proposed a few months ago. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780935410 From kevin.rushforth at oracle.com Wed Jan 21 20:21:43 2026 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Jan 2026 12:21:43 -0800 Subject: jfx26u open for JavaFX 26.0.1 backports Message-ID: <74f83995-a363-418e-97e2-ddce820aa7be@oracle.com> All, The jfx26u repo [1] is now open for JavaFX 26.0.1 backports (the April 2026 CPU release), with approval from one of the project leads. The general criteria is that we want to backport fixes for regressions introduced in JavaFX 26, third-party library updates, and a limited number of other important bug fixes. In most cases we'd like to see the fix "bake" in the mainline for a while before being backported to jfx26u. NOTE: Only those fixes that will NOT be backported to the jfx26 [2] stabilization branch are candidates for backporting to jfx26u. A backport intended for the JavaFX 26 code line will go into either the jfx26 branch (for the GA release of JavaFX 26) or the jfx26u repo (for a JavaFX 26.0.x update release), not both. We use a similar procedure for making the request and noting the approval as is used by the JDK updates releases -- by using JBS labels to request a backport and indicate approval or rejection. Here is the procedure: 1. If you are not sure whether something is a good candidate for backporting, ask on the mailing list or in the PR you want to backport. 2. Create the backport PR for jfx26u, either manually or using the "/backport" command. You can use Skara's "/approval" command to request approval. Skara will not mark a jfx26u PR as ready until approved. Let Johan or me know if you have any questions. Thanks. -- Kevin [1] https://github.com/openjdk/jfx26u [2] https://github.com/openjdk/jfx/tree/jfx26 From mfox at openjdk.org Wed Jan 21 20:24:22 2026 From: mfox at openjdk.org (Martin Fox) Date: Wed, 21 Jan 2026 20:24:22 GMT Subject: RFR: 8375578: Enable translucent window backdrops Message-ID: This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. There?s a crude manual test for trying out the different backdrop materials. java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. ------------- Commit messages: - Removed unused import - Merge remote-tracking branch 'upstream/master' into osbackdrop - OS supplied translucent window backdrops Changes: https://git.openjdk.org/jfx/pull/2048/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375578 Stats: 727 lines in 29 files changed: 642 ins; 64 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/2048.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2048/head:pull/2048 PR: https://git.openjdk.org/jfx/pull/2048 From mstrauss at openjdk.org Wed Jan 21 20:25:05 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:25:05 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 17:45:35 GMT, Andy Goryachev wrote: > What do you think of > > ``` > Set props = AttachedProperty.from(node); > ``` > > without the Node having to implement `HasAttachedProperties` interface? Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). In any case, having something along the lines of `AttachedProperty.from(node)` would entangle the implementation of `Node` (and other classes) with `AttachedProperty`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780988596 From mstrauss at openjdk.org Wed Jan 21 20:25:06 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:25:06 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: <3IQmTY8VrgJyCHY3ZpMfeoA8NnZGfpnTyTCE1QLki1Q=.7e0fa005-917b-48c3-8ba7-65657dfa9785@github.com> <0I--RQ4vOdpjRpfMIwNTodSWNTch3KU-_OcfB7XJJEk=.a00f5db4-c7c0-4ff4-8c65-c194292aebdd@github.com> Message-ID: <4IyoQT3pUG4KgWNEhduN54_YeIyie56RMn_DYIlA4l8=.d0e04641-9230-4d1d-bd2b-7762a0073704@github.com> On Wed, 21 Jan 2026 19:29:16 GMT, John Hendrikx wrote: > > the need for clearing is a bit overblown; > > I agree; my point is that the property belongs in the container, not the child node. I know - grandfathered, nothing we can do at this point. I understand that you don't like the idea of attached properties, and that you'd rather have narrow-scoped information colocated with layout containers. However, I'm glad that the JavaFX designers chose attached properties instead, as I think that this is a superior formalism. We're just finishing what they started. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3780990137 From angorya at openjdk.org Wed Jan 21 20:34:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 20:34:28 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:21:50 GMT, Michael Strau? wrote: > Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). you could also have `.of(Stage)`. > In any case, having something along the lines of `AttachedProperty.from(node)` would entangle the implementation of `Node` (and other classes) with `AttachedProperty`. How so? In fact, it completely separates the feature from whatever carrier is used. I really dislike this PR as it brings, in my opinion, unnecessary weight and code to the objects used everywhere for what seems to be a small side feature. I am ok with adding support to it, just not the way this PR does. I would say `AttachedProperty.of()` or something like that way is probably the least intrusive solution that I would support. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3781035626 From mstrauss at openjdk.org Wed Jan 21 20:48:14 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 20:48:14 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: References: Message-ID: <7W4H3MkQ2jwGl9dp5552LK5RMvA00Q1vHhI_Zu1Pg7I=.b543d0ad-fc79-42aa-be8f-424061f7bb75@github.com> On Wed, 21 Jan 2026 20:31:40 GMT, Andy Goryachev wrote: > > Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). > > you could also have `.of(Stage)`. Yes, and that brings in `Stage` into the API of `AttachedProperty`, where it doesn't belong. But I think I'm not even clear on what you are proposing here. This PR does two things: 1. It adds the `ReadOnlyProperty.getDeclaringClass()` method. 2. It adds the `AttachedProperty` interface, which property classes can implement. It seems like you don't object to the first addition, but only to the second addition. But what exactly does your proposed code do, then: Set props = AttachedProperty.from(node); What are these `AttachedProperty` objects that I can get from a node? They can't be the actual `Property` instances, as that's what you're objecting to. What can I do with these objects? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3781088062 From angorya at openjdk.org Wed Jan 21 20:58:47 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 20:58:47 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: <7W4H3MkQ2jwGl9dp5552LK5RMvA00Q1vHhI_Zu1Pg7I=.b543d0ad-fc79-42aa-be8f-424061f7bb75@github.com> References: <7W4H3MkQ2jwGl9dp5552LK5RMvA00Q1vHhI_Zu1Pg7I=.b543d0ad-fc79-42aa-be8f-424061f7bb75@github.com> Message-ID: On Wed, 21 Jan 2026 20:45:56 GMT, Michael Strau? wrote: >>> Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. >> >>> In any case, having something along the lines of `AttachedProperty.from(node)` would entangle the implementation of `Node` (and other classes) with `AttachedProperty`. >> >> How so? In fact, it completely separates the feature from whatever carrier is used. >> >> I really dislike this PR as it brings, in my opinion, unnecessary weight and code to the objects used everywhere for what seems to be a small side feature. I am ok with adding support to it, just not the way this PR does. >> >> I would say `AttachedProperty.of()` or something like that way is probably the least intrusive solution that I would support. > >> > Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. > > Yes, and that brings in `Stage` into the API of `AttachedProperty`, where it doesn't belong. > > But I think I'm not even clear on what you are proposing here. This PR does two things: > 1. It adds the `ReadOnlyProperty.getDeclaringClass()` method. > 2. It adds the `AttachedProperty` interface, which property classes can implement. > > It seems like you don't object to the first addition, but only to the second addition. But what exactly does your proposed code do, then: > > Set props = AttachedProperty.from(node); > > > What are these `AttachedProperty` objects that I can get from a node? They can't be the actual `Property` instances, as that's what you're objecting to. What can I do with these objects? @mstr2 : I don't understand the use case(s) then. @hjohn provided one: setting things like `-fx-hbox-hgrow` via CSS, so I thought that's the kind of property one can stash in the Node.properties. These properties might provide whatever extra information you want from the attached properties, if I understand all this correctly. I do not understand why you need to add unrelated and unused fields and methods to the regular property classes that neither need nor use it. Again, if I understand it correctly. Does your JEP explain the problem in sufficient detail so even an old timer like me who is perpetually stuck in Swing can understand? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3781126885 From mstrauss at openjdk.org Wed Jan 21 21:22:32 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 21:22:32 GMT Subject: RFR: 8375588: Enhanced property metadata [v2] In-Reply-To: <7W4H3MkQ2jwGl9dp5552LK5RMvA00Q1vHhI_Zu1Pg7I=.b543d0ad-fc79-42aa-be8f-424061f7bb75@github.com> References: <7W4H3MkQ2jwGl9dp5552LK5RMvA00Q1vHhI_Zu1Pg7I=.b543d0ad-fc79-42aa-be8f-424061f7bb75@github.com> Message-ID: <-Hydd9wCEI8Np6UjmfTvDww-qpQ8d-AhZf7DOvWrivg=.04e36135-71c1-4697-87c4-68a508429370@github.com> On Wed, 21 Jan 2026 20:45:56 GMT, Michael Strau? wrote: >>> Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. >> >>> In any case, having something along the lines of `AttachedProperty.from(node)` would entangle the implementation of `Node` (and other classes) with `AttachedProperty`. >> >> How so? In fact, it completely separates the feature from whatever carrier is used. >> >> I really dislike this PR as it brings, in my opinion, unnecessary weight and code to the objects used everywhere for what seems to be a small side feature. I am ok with adding support to it, just not the way this PR does. >> >> I would say `AttachedProperty.of()` or something like that way is probably the least intrusive solution that I would support. > >> > Attached properties are not exclusive to `Node`, we already have an attached property for `Stage` in JFX 26 (`HeaderBar.prefButtonHeight`). >> >> you could also have `.of(Stage)`. > > Yes, and that brings in `Stage` into the API of `AttachedProperty`, where it doesn't belong. > > But I think I'm not even clear on what you are proposing here. This PR does two things: > 1. It adds the `ReadOnlyProperty.getDeclaringClass()` method. > 2. It adds the `AttachedProperty` interface, which property classes can implement. > > It seems like you don't object to the first addition, but only to the second addition. But what exactly does your proposed code do, then: > > Set props = AttachedProperty.from(node); > > > What are these `AttachedProperty` objects that I can get from a node? They can't be the actual `Property` instances, as that's what you're objecting to. What can I do with these objects? > @mstr2 : I don't understand the use case(s) then. > > @hjohn provided one: setting things like `-fx-hbox-hgrow` via CSS, so I thought that's the kind of property one can stash in the Node.properties. These properties might provide whatever extra information you want from the attached properties, if I understand all this correctly. > > I do not understand why you need to add unrelated and unused fields and methods to the regular property classes that neither need nor use it. Again, if I understand it correctly. > > Does your JEP explain the problem in sufficient detail so even an old timer like me who is perpetually stuck in Swing can understand? Some enhancements are motivated by missing features, some are motivated by rough edges in a taxonomy. Consider the recent addition of pattern matching for primitives in Java: that's not a feature people were missing sorely, it's just what you get when you smooth out the rough edges. This PR falls into the second category: it smooths out rough edges in the JavaFX property system. Properties carry metadata to tell you about themselves: their name and the object to which they belong. The declaring class is a missing piece of information (and it's _certainly_ not unrelated, as you say). Whatever criticism you have about why property metadata exists, your criticism should then also be levied against the existing "bean" and "name" metadata. The argument is the same. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3781219715 From angorya at openjdk.org Wed Jan 21 23:20:32 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 21 Jan 2026 23:20:32 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:15:38 GMT, Christopher Schnick wrote: >> The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. >> >> If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. >> >> I tested this fix manually on Windows with a reproducer and it works as expected there > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments > - Improve positioning Thank you, somehow the latest changes make more sense by removing the dependency on the height change. (Just to be sure, the test https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/bugs/ComboBox_WrongLocation_8338145.java changes the number of items each time the popup is shown) Looks good on macOS 26.2 and windows 11. Please test it on Linux, though it should not have any platform-specific differences in my opinion. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2044#pullrequestreview-3689787781 From mstrauss at openjdk.org Wed Jan 21 23:54:00 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 21 Jan 2026 23:54:00 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 584: > 582: */ > 583: @SuppressWarnings("deprecation") > 584: public final void initBackdrop(StageBackdrop backdrop) { This API has the potential to age poorly, as enums are tricky to evolve. For example, what if a future backdrop type is configurable with a parameter? This could be improved by having the enum implement a sealed interface, so we can later add other backdrop types that can't neatly fit into an enum. I also wonder how graceful degradation works with this API. It might be useful to be able to model a request like: give me a glass backdrop with a set of parameters, and if the platform doesn't support that, give me a `TRANSIENT` backdrop, and if the platform doesn't support that, I just want an opaque backdrop. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2714753524 From duke at openjdk.org Thu Jan 22 03:00:29 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 22 Jan 2026 03:00:29 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> On Wed, 21 Jan 2026 23:51:41 GMT, Michael Strau? wrote: >> This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. >> >> There?s a crude manual test for trying out the different backdrop materials. >> >> java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java >> >> You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. >> >> If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. >> >> The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). >> >> On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. >> >> To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. > > modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 584: > >> 582: */ >> 583: @SuppressWarnings("deprecation") >> 584: public final void initBackdrop(StageBackdrop backdrop) { > > This API has the potential to age poorly, as enums are tricky to evolve. For example, what if a future backdrop type is configurable with a parameter? This could be improved by having the enum implement a sealed interface, so we can later add other backdrop types that can't neatly fit into an enum. > > I also wonder how graceful degradation works with this API. It might be useful to be able to model a request like: give me a glass backdrop with a set of parameters, and if the platform doesn't support that, give me a `TRANSIENT` backdrop, and if the platform doesn't support that, I just want an opaque backdrop. Could perhaps the scene preferences be used for things like this? E.g. similar to having access to the platform styling keys, a user could manually override some of them to achieve the same result as with enums. That would solve any potential parameters and the degradation problem better ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2715119943 From mstrauss at openjdk.org Thu Jan 22 03:40:26 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 03:40:26 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. modules/javafx.graphics/src/main/native-glass/mac/GlassHostView.m line 43: > 41: -(void)setBackdrop:(NSVisualEffectMaterial)material > 42: { > 43: NSVisualEffectView* effect = [[NSVisualEffectView alloc] initWithFrame: self.bounds]; Would this also work with `NSGlassEffectView` to get the Liquid Glass backdrop effect? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2715182074 From mstrauss at openjdk.org Thu Jan 22 03:58:56 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 03:58:56 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> References: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> Message-ID: On Thu, 22 Jan 2026 02:58:06 GMT, Christopher Schnick wrote: >> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 584: >> >>> 582: */ >>> 583: @SuppressWarnings("deprecation") >>> 584: public final void initBackdrop(StageBackdrop backdrop) { >> >> This API has the potential to age poorly, as enums are tricky to evolve. For example, what if a future backdrop type is configurable with a parameter? This could be improved by having the enum implement a sealed interface, so we can later add other backdrop types that can't neatly fit into an enum. >> >> I also wonder how graceful degradation works with this API. It might be useful to be able to model a request like: give me a glass backdrop with a set of parameters, and if the platform doesn't support that, give me a `TRANSIENT` backdrop, and if the platform doesn't support that, I just want an opaque backdrop. > > Could perhaps the scene preferences be used for things like this? E.g. similar to having access to the platform styling keys, a user could manually override some of them to achieve the same result as with enums. That would solve any potential parameters and the degradation problem better I'm not sure about scene preferences, as the supported backdrop materials are not exactly a _preference_. It's not something users can change about the system. How about something like this: public sealed interface StageBackdrop { enum Generic implements StageBackdrop { DEFAULT, WINDOW, TABBED, TRANSIENT } record Specialized(String name, Map parameters) implements StageBackdrop { public Specialized(String name) { this(name, Map.of()); } } } public class Stage { public final void initBackdrop(StageBackdrop... backdrop) { ... } } The `initBackdrop` method would take a list of options in order of preference. Maybe I could then configure my backdrop like so: myStage.initBackdrop( // first choice new StageBackdrop.Specialized( "NSGlassEffect", Map.of("style", "NSGlassEffectViewStyleClear") ), // second choice StageBackdrop.Generic.TRANSIENT ); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2715208532 From duke at openjdk.org Thu Jan 22 04:07:11 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 22 Jan 2026 04:07:11 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: <3kpO0-LV91z0wQ1zyqPBhrZfeBfpCPpszzWJ56fEnvo=.f2055a33-4b17-486b-9e08-be3b712e947d@github.com> On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 574: > 572: /** > 573: * Specifies the backdrop for this stage. This must be done prior to > 574: * making the stage visible. Is there is a reason on why this can't be changed later on? At least in my use cases, changing the backdrop type dynamically later on works without issues ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2715220921 From jbhaskar at openjdk.org Thu Jan 22 11:32:09 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 22 Jan 2026 11:32:09 GMT Subject: RFR: 8375225: WebIObserverTest fails with WebKit 623.1 Message-ID: Issue: WebIObserverTest fails with WebKit 623.1 due to float value comparison Solution: Adjusting the test because WebKit rect calculations moved to floating-point, so the intersection ratio is no longer an exact value. ------------- Commit messages: - add delta for IntersectionRatio as All rect width height calculation is now in Float Changes: https://git.openjdk.org/jfx/pull/2049/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375225 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/2049.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2049/head:pull/2049 PR: https://git.openjdk.org/jfx/pull/2049 From jhendrikx at openjdk.org Thu Jan 22 11:41:27 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 22 Jan 2026 11:41:27 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> Message-ID: On Thu, 22 Jan 2026 03:56:30 GMT, Michael Strau? wrote: >> Could perhaps the scene preferences be used for things like this? E.g. similar to having access to the platform styling keys, a user could manually override some of them to achieve the same result as with enums. That would solve any potential parameters and the degradation problem better > > I'm not sure about scene preferences, as the supported backdrop materials are not exactly a _preference_. It's not something users can change about the system. > > How about something like this: > > public sealed interface StageBackdrop { > > enum Generic implements StageBackdrop { > DEFAULT, > WINDOW, > TABBED, > TRANSIENT > } > > record Specialized(String name, Map parameters) implements StageBackdrop { > public Specialized(String name) { > this(name, Map.of()); > } > } > } > > > > public class Stage { > > public final void initBackdrop(StageBackdrop... backdrop) { > ... > } > } > > > The `initBackdrop` method would take a list of options in order of preference. Maybe I could then configure my backdrop like so: > > myStage.initBackdrop( > // first choice > new StageBackdrop.Specialized( > "NSGlassEffect", > Map.of("style", "NSGlassEffectViewStyleClear") > ), > > // second choice > StageBackdrop.Generic.TRANSIENT > ); Should we have a (new kind of) fallback system, or should we do this with the existing `Platform.isSupported(ConditionalFeature)` and have the user decide based on the result of that function? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2716542068 From jvos at openjdk.org Thu Jan 22 13:02:50 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Jan 2026 13:02:50 GMT Subject: [jfx26u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:38:26 GMT, Kevin Rushforth wrote: > This is a copy of the jfx25u README and CONTRIBUTING docs, changing 25 to 26. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx26u/pull/2#pullrequestreview-3692333098 From kcr at openjdk.org Thu Jan 22 13:56:10 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jan 2026 13:56:10 GMT Subject: [jfx26u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:38:26 GMT, Kevin Rushforth wrote: > This is a copy of the jfx25u README and CONTRIBUTING docs, changing 25 to 26. This pull request has now been integrated. Changeset: 380cba70 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx26u/commit/380cba709227330023075ce7ef3d3ef5a59e4a1a Stats: 271 lines in 2 files changed: 1 ins; 258 del; 12 mod 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6 ------------- PR: https://git.openjdk.org/jfx26u/pull/2 From kcr at openjdk.org Thu Jan 22 14:02:09 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jan 2026 14:02:09 GMT Subject: RFR: 8375225: WebIObserverTest fails with WebKit 623.1 In-Reply-To: References: Message-ID: <_WyVj33wZRmoeNet3LBQ9jGL_yh6Nb01FzmAypJ63ps=.21ca5498-28ea-4fbd-8616-06cc4cb9209a@github.com> On Thu, 22 Jan 2026 11:24:43 GMT, Jay Bhaskar wrote: > Issue: WebIObserverTest fails with WebKit 623.1 due to float value comparison > Solution: Adjusting the test because WebKit rect calculations moved to floating-point, so the intersection ratio is no longer an exact value. LGTM This is a simple test-only fix, so a single reviewer is sufficient. Also, I waive the 24-hour wait period so we can get this in for tonight's headful test run. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2049#pullrequestreview-3692599038 From hmeda at openjdk.org Thu Jan 22 14:21:39 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 22 Jan 2026 14:21:39 GMT Subject: [jfx26u] RFR: 8368572: Update WebKit to 623.1 Message-ID: clean Backport ------------- Commit messages: - Backport 422d3a954d531c9cca32b1401b5937b05b1b07fa Changes: https://git.openjdk.org/jfx26u/pull/3/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8368572 Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod Patch: https://git.openjdk.org/jfx26u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx26u/pull/3 From jbhaskar at openjdk.org Thu Jan 22 15:12:12 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 22 Jan 2026 15:12:12 GMT Subject: Integrated: 8375225: WebIObserverTest fails with WebKit 623.1 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:24:43 GMT, Jay Bhaskar wrote: > Issue: WebIObserverTest fails with WebKit 623.1 due to float value comparison > Solution: Adjusting the test because WebKit rect calculations moved to floating-point, so the intersection ratio is no longer an exact value. This pull request has now been integrated. Changeset: 055f827e Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/055f827e470e8f28a0d408fb8550ae759e068984 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8375225: WebIObserverTest fails with WebKit 623.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/2049 From kcr at openjdk.org Thu Jan 22 16:27:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 22 Jan 2026 16:27:46 GMT Subject: [jfx26u] RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 14:09:21 GMT, Hima Bindu Meda wrote: > clean Backport Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx26u/pull/3#pullrequestreview-3693361244 From mstrauss at openjdk.org Thu Jan 22 16:52:10 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 16:52:10 GMT Subject: RFR: 8364149: Conditional stylesheet imports [v3] In-Reply-To: References: Message-ID: <5SYQnUlckaUoOKn1jijKFfiGRy3hz2tcwVS1JVVZ_Q0=.33ad354a-fad3-4128-8ca4-9b63187e6040@github.com> > The [`@import`](https://www.w3.org/TR/css-cascade-5/#at-import) rule is extended to support conditional stylesheet imports: > > > @import [ | ] ? ; > > > Conceptually, a conditional import takes all rules of the referenced stylesheet, literally includes them at the location of the `@import` rule, and surrounds them with a `@media` rule with the specified ``. > > The implementation of this feature extends media queries with a context-free evaluation function: > > interface MediaQuery { > TriState evaluate(); // returns TRUE / FALSE / UNKNOWN > } > > > This mode of evaluation uses Kleene's strong trivalent logic to determine whether the media query will always match (it's a tautology), will never match (it's a contradiction), or whether it depends on the context or we simply don't know. > > Using this mechanism, a conditional stylesheet import that can never match will be skipped at runtime. Similarly, a conditional stylesheet import that will always match doesn't need the `` at all; its rules will be pasted verbatim into the main stylesheet. > > Note that this mechanism is _not_ meant to be a full-blown theorem solver. It won't detect that, for example, the following import conditions will always match: > > @import url("stylesheet.css") (width > 1000) or (width <= 1000); > > > Its purpose is an optimization for "obvious" cases. For example, at the moment the built-in themes use hard-coded conditions to include user-agent stylesheets at runtime: > > // in PlatformImpl.java: > if (isSupported(ConditionalFeature.INPUT_TOUCH)) { > uaStylesheets.add("com/sun/javafx/scene/control/skin/modena/touch.css"); > } > > In the future, we might have a way to test for `ConditionalFeature` flags that achieves the same thing, but with a public API available to all theme authors: > > @import url("com/sun/javafx/scene/control/skin/modena/touch.css") > (-fx-supports-conditional-feature: input-touch); Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into feature/conditional-import - Merge branch 'master' into feature/conditional-import - Conditional stylesheet imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2031/files - new: https://git.openjdk.org/jfx/pull/2031/files/12fc8915..5ef848c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2031&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2031&range=01-02 Stats: 506771 lines in 9034 files changed: 254882 ins; 189023 del; 62866 mod Patch: https://git.openjdk.org/jfx/pull/2031.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2031/head:pull/2031 PR: https://git.openjdk.org/jfx/pull/2031 From mstrauss at openjdk.org Thu Jan 22 16:53:09 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 16:53:09 GMT Subject: RFR: 8375588: Enhanced property metadata [v4] In-Reply-To: References: Message-ID: > Implementation of [enhanced property metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` classes. If a legacy constructor is used that doesn't specify the declaring class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is called the first time the `Simple<*>Property.getDeclaringClass()` method is called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the `test.util.property.PropertyMetadataVerifier` tool. It systematically tests all public and protected properties of a class, and ensures conformance to the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the `PropertyMetadataVerifier` rules in some way or shape. This PR won't address these issues, this will be done in a future cleanup PR. 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 five additional commits since the last revision: - Merge branch 'master' into feature/property-metadata - review changes - ReadOnlyProperty.getDeclaringClass() tests - doc - Enhanced property metadata ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2015/files - new: https://git.openjdk.org/jfx/pull/2015/files/1c624728..c1f8559a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2015&range=02-03 Stats: 506378 lines in 9017 files changed: 254550 ins; 188992 del; 62836 mod Patch: https://git.openjdk.org/jfx/pull/2015.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2015/head:pull/2015 PR: https://git.openjdk.org/jfx/pull/2015 From mstrauss at openjdk.org Thu Jan 22 16:59:47 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 16:59:47 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:45:24 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused field and not reachable code modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 43: > 41: import com.sun.scenario.effect.ImageData; > 42: import com.sun.scenario.effect.impl.prism.PrDrawable; > 43: import com.sun.scenario.effect.impl.prism.PrEffectHelper; The following imports are now unused and should be removed: import com.sun.scenario.effect.Blend.Mode; import com.sun.scenario.effect.FilterContext; import com.sun.scenario.effect.ImageData; import com.sun.scenario.effect.impl.prism.PrDrawable; import com.sun.scenario.effect.impl.prism.PrEffectHelper; ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2717776885 From duke at openjdk.org Thu Jan 22 17:04:26 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 22 Jan 2026 17:04:26 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: > This should improve the code quality of the class while preserving its original workings Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: Remove unused imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2043/files - new: https://git.openjdk.org/jfx/pull/2043/files/d29fcc80..e5637626 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2043&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2043.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2043/head:pull/2043 PR: https://git.openjdk.org/jfx/pull/2043 From mstrauss at openjdk.org Thu Jan 22 17:16:44 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 17:16:44 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: <4KrZjtX2mY6FzfCBcXtgo8PSze8l60r0vABOpfIGlGQ=.2ecd87f7-6bbf-4fd9-9dde-8b063e4a74da@github.com> On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Marked as reviewed by mstrauss (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2043#pullrequestreview-3693604013 From angorya at openjdk.org Thu Jan 22 17:22:33 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Jan 2026 17:22:33 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports What's the story with the `Blend.Mode` - is it still being used, do we need to remove it from other places, or we only remove it from this class? Does anyone know why we have two different `Blend.Mode` classes? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3785626965 From mfox at openjdk.org Thu Jan 22 18:53:23 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 22 Jan 2026 18:53:23 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> Message-ID: <5iATw_oK8YL9BwPTfQYEtkTyFGVsKbUTOeIZ0RSv2_o=.48107a78-726c-4542-92e3-fa2a24e6f4d4@github.com> On Thu, 22 Jan 2026 11:38:48 GMT, John Hendrikx wrote: >> I'm not sure about scene preferences, as the supported backdrop materials are not exactly a _preference_. It's not something users can change about the system. >> >> How about something like this: >> >> public sealed interface StageBackdrop { >> >> enum Generic implements StageBackdrop { >> DEFAULT, >> WINDOW, >> TABBED, >> TRANSIENT >> } >> >> record Specialized(String name, Map parameters) implements StageBackdrop { >> public Specialized(String name) { >> this(name, Map.of()); >> } >> } >> } >> >> >> >> public class Stage { >> >> public final void initBackdrop(StageBackdrop... backdrop) { >> ... >> } >> } >> >> >> The `initBackdrop` method would take a list of options in order of preference. Maybe I could then configure my backdrop like so: >> >> myStage.initBackdrop( >> // first choice >> new StageBackdrop.Specialized( >> "NSGlassEffect", >> Map.of("style", "NSGlassEffectViewStyleClear") >> ), >> >> // second choice >> StageBackdrop.Generic.TRANSIENT >> ); > > Should we have a (new kind of) fallback system, or should we do this with the existing `Platform.isSupported(ConditionalFeature)` and have the user decide based on the result of that function? I agree that an enum is inadequate. The two API's we have to work with (macOS and Win11) are based on enums; you specify the type of window or content (e.g. tooltip, menu, sidebar, window) and let the OS decide what material to use. macOS pro-actively enumerates a lot of different window types though it looks like many of them map to the same material under the hood. I'm not entirely sure the glass effect recently added to macOS is appropriate for JavaFX but it is a prime example of a specialized platform-specific backdrop that can't easily be squeezed into an enum. So, yes, we should expand StageBackdrop so we can provide more information. How to do that might be beyond my pay grade (I'm not a Java expert). I don't think the existing `Platform.isSupported()` API would be appropriate since it takes a separate enum type. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2718168893 From mstrauss at openjdk.org Thu Jan 22 19:02:03 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 19:02:03 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: <5iATw_oK8YL9BwPTfQYEtkTyFGVsKbUTOeIZ0RSv2_o=.48107a78-726c-4542-92e3-fa2a24e6f4d4@github.com> References: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> <5iATw_oK8YL9BwPTfQYEtkTyFGVsKbUTOeIZ0RSv2_o=.48107a78-726c-4542-92e3-fa2a24e6f4d4@github.com> Message-ID: On Thu, 22 Jan 2026 18:50:48 GMT, Martin Fox wrote: >> Should we have a (new kind of) fallback system, or should we do this with the existing `Platform.isSupported(ConditionalFeature)` and have the user decide based on the result of that function? > > I agree that an enum is inadequate. The two API's we have to work with (macOS and Win11) are based on enums; you specify the type of window or content (e.g. tooltip, menu, sidebar, window) and let the OS decide what material to use. macOS pro-actively enumerates a lot of different window types though it looks like many of them map to the same material under the hood. I'm not entirely sure the glass effect recently added to macOS is appropriate for JavaFX but it is a prime example of a specialized platform-specific backdrop that can't easily be squeezed into an enum. > > So, yes, we should expand StageBackdrop so we can provide more information. How to do that might be beyond my pay grade (I'm not a Java expert). I don't think the existing `Platform.isSupported()` API would be appropriate since it takes a separate enum type. > Should we have a (new kind of) fallback system, or should we do this with the existing `Platform.isSupported(ConditionalFeature)` and have the user decide based on the result of that function? Expanding on that question: if we have platform-specific backdrops that may have a big impact on styling and readability, stylesheets may want to query the actual backdrop used via media queries. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2718194820 From mfox at openjdk.org Thu Jan 22 19:05:15 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 22 Jan 2026 19:05:15 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 03:37:35 GMT, Michael Strau? wrote: >> This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. >> >> There?s a crude manual test for trying out the different backdrop materials. >> >> java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java >> >> You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. >> >> If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. >> >> The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). >> >> On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. >> >> To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. > > modules/javafx.graphics/src/main/native-glass/mac/GlassHostView.m line 43: > >> 41: -(void)setBackdrop:(NSVisualEffectMaterial)material >> 42: { >> 43: NSVisualEffectView* effect = [[NSVisualEffectView alloc] initWithFrame: self.bounds]; > > Would this also work with `NSGlassEffectView` to get the Liquid Glass backdrop effect? I'm experimenting with that now. I can get it to work but it only provides a nice effect for transparent stages. And it is an entirely different beast than the other backdrops. For example, it doesn't respond to the dark/light color scheme setting and rounds the corners even on transparent stages. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2718203968 From mstrauss at openjdk.org Thu Jan 22 19:07:28 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 19:07:28 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:20:03 GMT, Andy Goryachev wrote: > What's the story with the `Blend.Mode` - is it still being used, do we need to remove it from other places, or we only remove it from this class? > > Does anyone know why we have two different `Blend.Mode` classes? `javafx.scene.effect.BlendMode` is public API, `com.sun.scenario.effect.Blend.Mode` is an internal enum of the `Blend` effect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3786175238 From mfox at openjdk.org Thu Jan 22 20:09:29 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 22 Jan 2026 20:09:29 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: <3kpO0-LV91z0wQ1zyqPBhrZfeBfpCPpszzWJ56fEnvo=.f2055a33-4b17-486b-9e08-be3b712e947d@github.com> References: <3kpO0-LV91z0wQ1zyqPBhrZfeBfpCPpszzWJ56fEnvo=.f2055a33-4b17-486b-9e08-be3b712e947d@github.com> Message-ID: On Thu, 22 Jan 2026 04:04:48 GMT, Christopher Schnick wrote: >> This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. >> >> There?s a crude manual test for trying out the different backdrop materials. >> >> java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java >> >> You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. >> >> If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. >> >> The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). >> >> On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. >> >> To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. > > modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 574: > >> 572: /** >> 573: * Specifies the backdrop for this stage. This must be done prior to >> 574: * making the stage visible. > > Is there is a reason on why this can't be changed later on? At least in my use cases, changing the backdrop type dynamically later on works without issues I prototyped a version of this for Win10. On that platform we have to roll our own backdrops using DirectComposition or Windows.UI.Composition and that requires building the HWND a little differently, firing up a different painter, and re-plumbing the way pixels are delivered from Prism. I'm not entirely sure we can set all that up after the HWND is created. It's just far far easier to have the backdrop in hand from the start. (Well, all we really need to know when we create the platform window is that we'll be using a backdrop. The actual backdrop choice could be specified dynamically later but I wasn't sure what purpose that would serve.) I'm not sure how this would work on Linux. The Wayland folks recently added an extension for blurring window backgrounds and it looks like it can be dynamically added and removed but I can't test that right now and have no idea which compositors have implemented it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2718445867 From jvos at openjdk.org Thu Jan 22 20:18:49 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Jan 2026 20:18:49 GMT Subject: [jfx25u] RFR: 8368572: Update WebKit to 623.1 Message-ID: To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. DMARC Info : Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1 Result= none Questions and more information: * You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network. * If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions * Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take. * If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel. Thank you in advance for your attention to this matter. Hi all, This pull request contains a backport of commit [422d3a95](https://github.com/openjdk/jfx/commit/422d3a954d531c9cca32b1401b5937b05b1b07fa) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. Thanks! ------------- Commit messages: - Backport 422d3a954d531c9cca32b1401b5937b05b1b07fa Changes: https://git.openjdk.org/jfx25u/pull/46/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8368572 Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod Patch: https://git.openjdk.org/jfx25u/pull/46.diff Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/46/head:pull/46 PR: https://git.openjdk.org/jfx25u/pull/46 From jvos at openjdk.org Thu Jan 22 20:22:14 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Jan 2026 20:22:14 GMT Subject: [jfx21u] RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7 Message-ID: To protect against unauthorized use of the Oracle email brand, we will be implementing a strict DMARC policy as part of our email security. DMARC (Domain-based Message Authentication, Reporting and Conformance) will help protect against phishing attacks, spam campaigns, and other malicious activities. With this implementation, emails sent on behalf of ANY Oracle owned domain will be restricted if they fail DMARC compliance. DMARC Info : Record= v=DMARC1;p=none;rua=mailto:dmarc_rua at emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf at emaildefense.proofpoint.com;fo=1 Result= none Questions and more information: * You may need to take action if you're responsible for email flow from Oracle Cloud, OCI, or acquisition domains. Senders in this category are treated as external emails since they operate outside of Oracle's internal network. * If you are using the OCI Email Delivery Service, ensure you generate DKIM for your related Header From Domain - refer to https://docs.oracle.com/en-us/iaas/Content/Email/Tasks/configuredkim.htm more info can be found here https://confluence.oraclecorp.com/confluence/display/EMAIL/DMARC+for+Oracle+IT+and+Email+Delivery+Frequently+Asked+Questions * Refer to the DMARC FAQ https://confluence.oraclecorp.com/confluence/display/OITGLOBAL/DMARC+Global+FAQ to learn more about DMARC, if your emails may be affected, and actions you need to take. * If you have questions, reach out to the #oracle-owned-domains-dmarc Slack channel. Thank you in advance for your attention to this matter. Hi all, This pull request contains a backport of commit [adb6c11e](https://github.com/openjdk/jfx/commit/adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Jay Bhaskar on 13 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora. Thanks! ------------- Commit messages: - Backport adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e Changes: https://git.openjdk.org/jfx21u/pull/110/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=110&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/jfx21u/pull/110.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/110/head:pull/110 PR: https://git.openjdk.org/jfx21u/pull/110 From jvos at openjdk.org Thu Jan 22 20:30:17 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Jan 2026 20:30:17 GMT Subject: [jfx21u] Integrated: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:14:27 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [adb6c11e](https://github.com/openjdk/jfx/commit/adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Jay Bhaskar on 13 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora. > > Thanks! This pull request has now been integrated. Changeset: e10e5d47 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/e10e5d47bb21447bf9bafd2826f24219814cb007 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/jfx21u/pull/110 From mfox at openjdk.org Thu Jan 22 20:32:16 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 22 Jan 2026 20:32:16 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: <76usK_QZzY5qzEDTRGjK1cij-Q5Oucv2ngEVLgCZv4U=.a933f4ec-11d3-4ca7-8e9f-e533dd307eeb@github.com> <5iATw_oK8YL9BwPTfQYEtkTyFGVsKbUTOeIZ0RSv2_o=.48107a78-726c-4542-92e3-fa2a24e6f4d4@github.com> Message-ID: On Thu, 22 Jan 2026 18:58:58 GMT, Michael Strau? wrote: >> I agree that an enum is inadequate. The two API's we have to work with (macOS and Win11) are based on enums; you specify the type of window or content (e.g. tooltip, menu, sidebar, window) and let the OS decide what material to use. macOS pro-actively enumerates a lot of different window types though it looks like many of them map to the same material under the hood. I'm not entirely sure the glass effect recently added to macOS is appropriate for JavaFX but it is a prime example of a specialized platform-specific backdrop that can't easily be squeezed into an enum. >> >> So, yes, we should expand StageBackdrop so we can provide more information. How to do that might be beyond my pay grade (I'm not a Java expert). I don't think the existing `Platform.isSupported()` API would be appropriate since it takes a separate enum type. > >> Should we have a (new kind of) fallback system, or should we do this with the existing `Platform.isSupported(ConditionalFeature)` and have the user decide based on the result of that function? > > Expanding on that question: if we have platform-specific backdrops that may have a big impact on styling and readability, stylesheets may want to query the actual backdrop used via media queries. The platforms seem to assume you'll draw content on the backdrop using the PlatformPreference colors (there's no way of asking the platforms for backdrop-specific color information). But it still might be good for the stylesheets to know which backdrop is in effect. A more interesting question is whether a stylesheet can ask for a backdrop to be applied. The CSS machinery isn't set up for this; it's designed to apply styles to nodes, not windows (AFIK). And you probably don't want to apply a backdrop to, say, a menu or tooltip since the backdrop would fill the entire stage forcing it to be rectangular (no rounded corners). If the CSS called for a drop shadow the backdrop would be behind the shadow. I considered ways of fixing this but didn't come up with a workable solution. I'll be traveling for a few days so it might be a while before I re-enter the conversation. Thanks for all the feedback! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2718524353 From jvos at openjdk.org Thu Jan 22 20:44:22 2026 From: jvos at openjdk.org (Johan Vos) Date: Thu, 22 Jan 2026 20:44:22 GMT Subject: [jfx17u] RFR: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7 Message-ID: Hi all, This pull request contains a backport of commit [adb6c11e](https://github.com/openjdk/jfx/commit/adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Jay Bhaskar on 13 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora. Thanks! ------------- Commit messages: - Backport adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e Changes: https://git.openjdk.org/jfx17u/pull/247/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=247&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/jfx17u/pull/247.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/247/head:pull/247 PR: https://git.openjdk.org/jfx17u/pull/247 From mhanl at openjdk.org Thu Jan 22 22:03:02 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 22 Jan 2026 22:03:02 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 19:04:19 GMT, Michael Strau? wrote: > What's the story with the `Blend.Mode` - is it still being used, do we need to remove it from other places, or we only remove it from this class? > > Does anyone know why we have two different `Blend.Mode` classes? Related to: https://github.com/openjdk/jfx/pull/1846 ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3786968923 From angorya at openjdk.org Thu Jan 22 22:07:52 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 22 Jan 2026 22:07:52 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports > Related to: #1846 if these two are exactly the same (I haven't looked), why not use the public one? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3786983151 From mstrauss at openjdk.org Thu Jan 22 22:24:34 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 22 Jan 2026 22:24:34 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: <-y99Tk7dBouWXfQFVY15ZOdIf0xtR_u-ZIOjjJmkaoA=.90110ae4-8640-441f-be4f-1f26f97e1571@github.com> On Thu, 22 Jan 2026 22:04:47 GMT, Andy Goryachev wrote: > > Related to: #1846 > > if these two are exactly the same (I haven't looked), why not use the public one? Reduces coupling between different systems that shouldn't be entangled with each other. If done correctly, you'll get systems that are easier to develop in isolation, easier to test, and easier to maintain. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3787043435 From arapte at openjdk.org Fri Jan 23 02:05:05 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 23 Jan 2026 02:05:05 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS Message-ID: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues. Changing the pipeline to default early in jfx27 would offer more testing. If required one can always use es2 pipeline by passing `-Dprism.order=es2` ------------- Commit messages: - default pipeline mtl Changes: https://git.openjdk.org/jfx/pull/2050/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373091 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2050.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2050/head:pull/2050 PR: https://git.openjdk.org/jfx/pull/2050 From jbhaskar at openjdk.org Fri Jan 23 05:45:37 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 23 Jan 2026 05:45:37 GMT Subject: [jfx26u] RFR: 8375225: WebIObserverTest fails with WebKit 623.1 Message-ID: A clean backport for jfx26u. The fix is for WebIObserverTest fails after webkit upgrade 623.1. The test fails without fix and passes with fix. ------------- Commit messages: - Backport 055f827e470e8f28a0d408fb8550ae759e068984 Changes: https://git.openjdk.org/jfx26u/pull/4/files Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=4&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375225 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx26u/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx26u/pull/4 From hmeda at openjdk.org Fri Jan 23 06:33:55 2026 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 23 Jan 2026 06:33:55 GMT Subject: [jfx26u] Integrated: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 14:09:21 GMT, Hima Bindu Meda wrote: > clean Backport This pull request has now been integrated. Changeset: 179fd49a Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx26u/commit/179fd49a3c03989207c0f90d0f188a326276e208 Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod 8368572: Update WebKit to 623.1 Reviewed-by: kcr Backport-of: 422d3a954d531c9cca32b1401b5937b05b1b07fa ------------- PR: https://git.openjdk.org/jfx26u/pull/3 From duke at openjdk.org Fri Jan 23 07:39:20 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 23 Jan 2026 07:39:20 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 342: > 340: break; > 341: case WM_DWMCOMPOSITIONCHANGED: > 342: if (m_isUnified || m_hasBackdrop) { Should a backdrop automatically set the window margin akin to UNIFIED (and maybe EXTENDED)? In my opinion, this should be left to the stage style for consistency. Like if I use the normal stage style with a backdrop, I might not want the full backdrop to be visible like that. Maybe I only want the backdrop the be visible in the title bar. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2719967925 From duke at openjdk.org Fri Jan 23 08:07:39 2026 From: duke at openjdk.org (Christopher Schnick) Date: Fri, 23 Jan 2026 08:07:39 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:15:38 GMT, Christopher Schnick wrote: >> The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. >> >> If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. >> >> I tested this fix manually on Windows with a reproducer and it works as expected there > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments > - Improve positioning I tested in on Ubuntu 24.04 with Gnome. The original issue occurs there, I'm not sure why the JBS ticket reproduction showed something different. With this PR, the issue is fixed there as well for me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2044#issuecomment-3788924478 From jvos at openjdk.org Fri Jan 23 08:40:02 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Jan 2026 08:40:02 GMT Subject: [jfx17u] Integrated: 8367578: Additional WebKit 622.1 fixes from WebKitGTK 2.48.7 In-Reply-To: References: Message-ID: <7d0SA9YeUxYbzXHNKWHqd4CC9NOO4xlzpdN5Lu93qCg=.7087e5dc-d966-4528-a9ff-34962384155c@github.com> On Thu, 22 Jan 2026 20:36:04 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [adb6c11e](https://github.com/openjdk/jfx/commit/adb6c11e34c6e08e158e8a9ec6aa769ad9de9a4e) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Jay Bhaskar on 13 Oct 2025 and was reviewed by Kevin Rushforth and Joeri Sykora. > > Thanks! This pull request has now been integrated. Changeset: 1e71ef4a Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/1e71ef4a306d41f6fe699e9003f7bfafde9a0c29 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/jfx17u/pull/247 From jvos at openjdk.org Fri Jan 23 09:18:17 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Jan 2026 09:18:17 GMT Subject: [jfx17u] RFR: 8376175: CanvasTest fails with older junit on jfx17u Message-ID: This PR fixes a test compilation failure due to junit5 annotations being used. Use @Ignore instead of @Disabled on junit4 ------------- Commit messages: - Use @Ignore instead of @Disabled on junit4 Changes: https://git.openjdk.org/jfx17u/pull/248/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376175 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/248.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/248/head:pull/248 PR: https://git.openjdk.org/jfx17u/pull/248 From jpereda at openjdk.org Fri Jan 23 09:44:36 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 23 Jan 2026 09:44:36 GMT Subject: [jfx25u] RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:07:22 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [422d3a95](https://github.com/openjdk/jfx/commit/422d3a954d531c9cca32b1401b5937b05b1b07fa) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. > > Thanks! Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx25u/pull/46#pullrequestreview-3696647952 From jvos at openjdk.org Fri Jan 23 09:44:37 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Jan 2026 09:44:37 GMT Subject: [jfx25u] RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:07:22 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [422d3a95](https://github.com/openjdk/jfx/commit/422d3a954d531c9cca32b1401b5937b05b1b07fa) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. > > Thanks! jenkins builds/tests succeeded. ------------- PR Comment: https://git.openjdk.org/jfx25u/pull/46#issuecomment-3789332225 From jvos at openjdk.org Fri Jan 23 09:53:32 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Jan 2026 09:53:32 GMT Subject: [jfx25u] Integrated: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: <5-6qQUMrzofK6kBME23VgUWCnUWB0tdwCUEotbAe1sM=.e596e368-7b57-4f08-b763-eb15a090895e@github.com> On Thu, 22 Jan 2026 20:07:22 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [422d3a95](https://github.com/openjdk/jfx/commit/422d3a954d531c9cca32b1401b5937b05b1b07fa) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. > > Thanks! This pull request has now been integrated. Changeset: 513e43d6 Author: Johan Vos URL: https://git.openjdk.org/jfx25u/commit/513e43d66ae9ce169a53a331c44f44879d35646e Stats: 505662 lines in 8991 files changed: 253929 ins; 188948 del; 62785 mod 8368572: Update WebKit to 623.1 Reviewed-by: jpereda Backport-of: 422d3a954d531c9cca32b1401b5937b05b1b07fa ------------- PR: https://git.openjdk.org/jfx25u/pull/46 From jvos at openjdk.org Fri Jan 23 10:24:17 2026 From: jvos at openjdk.org (Johan Vos) Date: Fri, 23 Jan 2026 10:24:17 GMT Subject: [jfx25u] RFR: 8367045: [Linux] Dead keys not working In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:02:41 GMT, Martin Fox wrote: > Hi all, > > This pull request contains a backport of commit [d5e817d6](https://github.com/openjdk/jfx/commit/d5e817d6e4f28bb1e14292f17f7fe95f5d001487) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Martin Fox on 4 Oct 2025 and was reviewed by Lukasz Kostyra and Thiago Milczarek Sayao. > > Thanks! This is indeed a serious regression. The fix touches a small amount of code in just 2 files, and is very unlikely to have negative side-effects. ------------- PR Comment: https://git.openjdk.org/jfx25u/pull/45#issuecomment-3789535498 From mhanl at openjdk.org Fri Jan 23 13:55:56 2026 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 23 Jan 2026 13:55:56 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: <3Zfn9Syzl-PY1XNRrEvvwK90fdj04R7FTmdyYq_ACi0=.0f1c32d4-a253-4e00-bb51-18b3f3844990@github.com> On Sun, 11 Jan 2026 17:01:32 GMT, youngledo wrote: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: Message-ID: On Fri, 23 Jan 2026 05:38:19 GMT, Jay Bhaskar wrote: > A clean backport for jfx26u. The fix is for WebIObserverTest fails after webkit upgrade 623.1. The test fails without fix and passes with fix. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx26u/pull/4#pullrequestreview-3697736691 From duke at openjdk.org Fri Jan 23 14:22:00 2026 From: duke at openjdk.org (youngledo) Date: Fri, 23 Jan 2026 14:22:00 GMT Subject: Withdrawn: Fix VirtualFlow performance regression in ListView scrolling In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 17:01:32 GMT, youngledo wrote: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: Message-ID: On Fri, 23 Jan 2026 05:38:19 GMT, Jay Bhaskar wrote: > A clean backport for jfx26u. The fix is for WebIObserverTest fails after webkit upgrade 623.1. The test fails without fix and passes with fix. This pull request has now been integrated. Changeset: cf7de320 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx26u/commit/cf7de3208e421266a8e19b9101e550949b1af95d Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8375225: WebIObserverTest fails with WebKit 623.1 Reviewed-by: kcr Backport-of: 055f827e470e8f28a0d408fb8550ae759e068984 ------------- PR: https://git.openjdk.org/jfx26u/pull/4 From kcr at openjdk.org Fri Jan 23 23:12:50 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 23 Jan 2026 23:12:50 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS In-Reply-To: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> Message-ID: On Fri, 23 Jan 2026 01:58:07 GMT, Ambarish Rapte wrote: > The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. > During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues. > Changing the pipeline to default early in jfx27 would offer more testing. > > If required one can always use es2 pipeline by passing `-Dprism.order=es2` LGTM. As you say, the metal pipeline is well-tested. I presume you have (or will) run a CI headful test job? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2050#pullrequestreview-3700073673 From mfox at openjdk.org Sun Jan 25 00:11:13 2026 From: mfox at openjdk.org (Martin Fox) Date: Sun, 25 Jan 2026 00:11:13 GMT Subject: [jfx25u] Integrated: 8367045: [Linux] Dead keys not working In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:02:41 GMT, Martin Fox wrote: > Hi all, > > This pull request contains a backport of commit [d5e817d6](https://github.com/openjdk/jfx/commit/d5e817d6e4f28bb1e14292f17f7fe95f5d001487) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Martin Fox on 4 Oct 2025 and was reviewed by Lukasz Kostyra and Thiago Milczarek Sayao. > > Thanks! This pull request has now been integrated. Changeset: b63a5b37 Author: Martin Fox URL: https://git.openjdk.org/jfx25u/commit/b63a5b37810f6bea06244b85912a74decda5a724 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod 8367045: [Linux] Dead keys not working Backport-of: d5e817d6e4f28bb1e14292f17f7fe95f5d001487 ------------- PR: https://git.openjdk.org/jfx25u/pull/45 From tsayao at openjdk.org Sun Jan 25 16:05:56 2026 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 25 Jan 2026 16:05:56 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v72] 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 88 commits: - Review fixes - sync headerbar changes - Merge branch 'master' into 8354943 # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp # modules/javafx.graphics/src/main/native-glass/gtk/glass_window.h - Merge branch 'master' into 8354943 # Conflicts: # tests/system/src/test/java/test/util/Util.java - Merge branch 'master' into 8354943 - Remote assumeTrue for JDK-8364547 - Merge branch 'master' into 8354943 - 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 - ... and 78 more: https://git.openjdk.org/jfx/compare/055f827e...01e84817 ------------- Changes: https://git.openjdk.org/jfx/pull/1789/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=71 Stats: 4132 lines in 28 files changed: 2710 ins; 783 del; 639 mod Patch: https://git.openjdk.org/jfx/pull/1789.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789 PR: https://git.openjdk.org/jfx/pull/1789 From tsayao at openjdk.org Sun Jan 25 16:05:59 2026 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 25 Jan 2026 16:05:59 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v71] In-Reply-To: References: Message-ID: <2OErMUrvM0qIy5fmpb5kZ664AWIFToczsGTn0TjAJpk=.1a113399-edf6-46c9-b4af-a5adbc53dbf2@github.com> On Fri, 16 Jan 2026 18:20:58 GMT, Martin Fox wrote: >> 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 85 commits: >> >> - Merge branch 'master' into 8354943 >> >> # Conflicts: >> # tests/system/src/test/java/test/util/Util.java >> - Merge branch 'master' into 8354943 >> - Remote assumeTrue for JDK-8364547 >> - Merge branch 'master' into 8354943 >> - 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 >> - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205 > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 134: > >> 132: minimizeImpl(ptr, minimize); >> 133: >> 134: if (!isVisible()) { > > This check is new and only happens when minimizing, not maximizing. Under what conditions does this occur? It was a leftover from development. I've removed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2725656919 From tsayao at openjdk.org Sun Jan 25 16:12:19 2026 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 25 Jan 2026 16:12:19 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v71] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:37:35 GMT, Martin Fox wrote: >> 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 85 commits: >> >> - Merge branch 'master' into 8354943 >> >> # Conflicts: >> # tests/system/src/test/java/test/util/Util.java >> - Merge branch 'master' into 8354943 >> - Remote assumeTrue for JDK-8364547 >> - Merge branch 'master' into 8354943 >> - 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 >> - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205 > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 822: > >> 820: >> 821: void WindowContext::update_initial_state() { >> 822: GdkWindowState state = gdk_window_get_state(gdk_window); > > This handles the case where set_maximized, set_minimized, or enter_fullscreen are called after the peer is created but before it's mapped. > > Oh no! > > This is an ugly part of the code. For one, when these state flags are set on a Java Window before it is shown the code just stashes them away. When the Window is shown the code applies them in a fixed order: fullscreen, iconified, maximized. So if iconified and maximized are both set the window should end up maximized. > > For two, the documentation and code treat iconified/maximized/restored as a trio of mutually exclusive states which are entirely separate from fullscreen (which overrides them all). This is probably a relic of the days when fullscreen was implemented using an entirely separate window. In practice the platform code doesn't honor this separation and if you mix fullscreen with iconified or maximized you'll get different results on different platforms (and the Java state is likely to get confused). > > The end result is a bit of a mess. The good news is this leads to the sort of spec violations and bugs that no one notices. > > TL;DR - I think the correct order to apply these flags is iconified, maximized, and then fullscreen. This is different than the order the core code uses but, again, as far as it's concerned fullscreen overrides maximized and iconified. To honor that it should be applied last. I've changed the order and also added a check to not iconify when the flag is also set to maximize, because the java side would set `iconified = false` when maximized. Yeah, it seems it needs a refactor that would include changes on the java side, but it's not a priority because probably no one will notice it. The documentation on `Stage` also needs some care. > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1059: > >> 1057: >> 1058: void WindowContext::notify_current_sizes() { >> 1059: notify_window_resize(is_maximized() > > This should also be checking for is_iconified. Again, unlikely to be introducing a new bug so this fix can be pushed to a separate PR. Fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2725666846 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2725667057 From tsayao at openjdk.org Sun Jan 25 16:25:15 2026 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 25 Jan 2026 16:25:15 GMT Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v71] In-Reply-To: References: Message-ID: <4uaj7ToNIUiSpjqR449pYEI7By_qf8FELbLXZsFj2_0=.063972e1-04af-4e55-a34a-711e30cfc66d@github.com> On Fri, 16 Jan 2026 18:39:03 GMT, Martin Fox wrote: >> 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 85 commits: >> >> - Merge branch 'master' into 8354943 >> >> # Conflicts: >> # tests/system/src/test/java/test/util/Util.java >> - Merge branch 'master' into 8354943 >> - Remote assumeTrue for JDK-8364547 >> - Merge branch 'master' into 8354943 >> - 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 >> - ... and 75 more: https://git.openjdk.org/jfx/compare/6626e013...7e3c3205 > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 190: > >> 188: >> 189: window_size.setOnChange([this](const Size& size) { >> 190: notify_window_resize(is_maximized() > > There is a very minor bug here that's also present in the master branch. If the size of a window is changed when it's iconified it can't be un-iconified. This notification tells the Java Window that it has been restored even though it's still iconified which confuses the bookkeeping. > > This is an old bug so I would be fine if we just enter a bug report and push the fix off to another PR. Unfortunately there's no way to write an automated test. That would require adding a call to query the OS for the window's state so we can compare it with the state the Java Window is tracking. Good catch. I've fixed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2725682684 From jpereda at openjdk.org Sun Jan 25 19:35:15 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Sun, 25 Jan 2026 19:35:15 GMT Subject: [jfx17u] RFR: 8376175: CanvasTest fails with older junit on jfx17u In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:11:07 GMT, Johan Vos wrote: > This PR fixes a test compilation failure due to junit5 annotations being used. > > Use @Ignore instead of @Disabled on junit4 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/248#pullrequestreview-3704195448 From jvos at openjdk.org Sun Jan 25 19:46:12 2026 From: jvos at openjdk.org (Johan Vos) Date: Sun, 25 Jan 2026 19:46:12 GMT Subject: [jfx17u] Integrated: 8376175: CanvasTest fails with older junit on jfx17u In-Reply-To: References: Message-ID: <5UUNgYVmTZ0XSFsu0FxAp2kOd7Ql6k3PKrGwcZdTzMo=.4f37b318-3677-49f2-bd82-edb728752380@github.com> On Fri, 23 Jan 2026 09:11:07 GMT, Johan Vos wrote: > This PR fixes a test compilation failure due to junit5 annotations being used. > > Use @Ignore instead of @Disabled on junit4 This pull request has now been integrated. Changeset: 8d9f4ca5 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/8d9f4ca5909335335111d79d6bd7fd4816bea159 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8376175: CanvasTest fails with older junit on jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/248 From mfox at openjdk.org Mon Jan 26 01:48:11 2026 From: mfox at openjdk.org (Martin Fox) Date: Mon, 26 Jan 2026 01:48:11 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 07:36:57 GMT, Christopher Schnick wrote: >> This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. >> >> There?s a crude manual test for trying out the different backdrop materials. >> >> java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java >> >> You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. >> >> If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. >> >> The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). >> >> On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. >> >> To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. > > modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 342: > >> 340: break; >> 341: case WM_DWMCOMPOSITIONCHANGED: >> 342: if (m_isUnified || m_hasBackdrop) { > > Should a backdrop automatically set the window margin akin to UNIFIED (and maybe EXTENDED)? In my opinion, this should be left to the stage style for consistency. > > Like if I use the normal stage style with a backdrop, I might not want the full backdrop to be visible like that. Maybe I only want the backdrop the be visible in the title bar. Good question. I had to do this to make the backdrops work. I tweaked Prism to ensure the swap chain supported an alpha channel but apparently that's not enough. To get D3D9 to alpha composite onto the backdrop we have to make this call to invoke the old Aero glass logic (the effect UNIFIED was originally designed for). I'll keep looking into this but for now when there's a backdrop DECORATED and UNIFIED look the same. I'll also take a look at DWMSBT_AUTO which states that it only draws the backdrop in the title bar but doesn't give us any control over the effect. Most Microsoft apps that employ these backdrops extend the backdrop into the title bar though there's a lot of subtle variation (and then there's Weather which looks like it was written by a different company). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2048#discussion_r2726138789 From jpereda at openjdk.org Mon Jan 26 12:03:30 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 26 Jan 2026 12:03:30 GMT Subject: [jfx21u] RFR: 8376299: [jfx21u] backported test requires more recent JDK Message-ID: This PR removes the AutoCloseable feature from a test, as it is not supported by the min build and target JDK 17 that is set for JavaFX 21u. ------------- Commit messages: - Remove AutoCloseable feature from test Changes: https://git.openjdk.org/jfx21u/pull/111/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376299 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/111.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/111/head:pull/111 PR: https://git.openjdk.org/jfx21u/pull/111 From jvos at openjdk.org Mon Jan 26 12:06:30 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:06:30 GMT Subject: [jfx17u] RFR: 8368572: Update WebKit to 623.1 Message-ID: Hi all, This pull request contains a backport of commit 422d3a95 from the openjdk/jfx repository. The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. Thanks! ------------- Commit messages: - Backport 422d3a954d531c9cca32b1401b5937b05b1b07fa Changes: https://git.openjdk.org/jfx17u/pull/249/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368572 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/249.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/249/head:pull/249 PR: https://git.openjdk.org/jfx17u/pull/249 From jvos at openjdk.org Mon Jan 26 12:13:40 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:13:40 GMT Subject: [jfx17u] RFR: 8347937: Canvas pattern test fails and crashes on WebKit 620.1 Message-ID: Hi all, This pull request contains a backport of commit fd099a7f from the openjdk/jfx repository. The commit being backported was authored by Jay Bhaskar on 24 Mar 2025 and was reviewed by Kevin Rushforth and Ambarish Rapte. Thanks! ------------- Commit messages: - Backport fd099a7f067c1694c1c12a8fa02b1e7eda51201f Changes: https://git.openjdk.org/jfx17u/pull/250/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=250&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347937 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/250.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/250/head:pull/250 PR: https://git.openjdk.org/jfx17u/pull/250 From jvos at openjdk.org Mon Jan 26 12:14:37 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:14:37 GMT Subject: [jfx17u] RFR: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 11:59:20 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 422d3a95 from the openjdk/jfx repository. > > The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. > > Thanks! wrong title ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/249#issuecomment-3799261572 From jvos at openjdk.org Mon Jan 26 12:14:37 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:14:37 GMT Subject: [jfx17u] Withdrawn: 8368572: Update WebKit to 623.1 In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 11:59:20 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 422d3a95 from the openjdk/jfx repository. > > The commit being backported was authored by Hima Bindu Meda on 21 Jan 2026 and was reviewed by Kevin Rushforth, Joeri Sykora and Johan Vos. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx17u/pull/249 From jvos at openjdk.org Mon Jan 26 12:37:03 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:37:03 GMT Subject: [jfx21u] RFR: 8376299: [jfx21u] backported test requires more recent JDK In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 11:57:31 GMT, Jose Pereda wrote: > This PR removes the AutoCloseable feature from a test, as it is not supported by the min build and target JDK 17 that is set for JavaFX 21u. passes on 17 ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx21u/pull/111#pullrequestreview-3705846199 From jpereda at openjdk.org Mon Jan 26 12:47:15 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 26 Jan 2026 12:47:15 GMT Subject: [jfx17u] RFR: 8347937: Canvas pattern test fails and crashes on WebKit 620.1 In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:08:22 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit fd099a7f from the openjdk/jfx repository. > > The commit being backported was authored by Jay Bhaskar on 24 Mar 2025 and was reviewed by Kevin Rushforth and Ambarish Rapte. > > Thanks! Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/250#pullrequestreview-3705880902 From jvos at openjdk.org Mon Jan 26 12:47:16 2026 From: jvos at openjdk.org (Johan Vos) Date: Mon, 26 Jan 2026 12:47:16 GMT Subject: [jfx17u] Integrated: 8347937: Canvas pattern test fails and crashes on WebKit 620.1 In-Reply-To: References: Message-ID: <_eDQZ_w7fPjA6GasRyMIZTwGveJhdcpAUOIlhZbswuo=.833d90a3-cf3d-4489-ba90-7943b5769460@github.com> On Mon, 26 Jan 2026 12:08:22 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit fd099a7f from the openjdk/jfx repository. > > The commit being backported was authored by Jay Bhaskar on 24 Mar 2025 and was reviewed by Kevin Rushforth and Ambarish Rapte. > > Thanks! This pull request has now been integrated. Changeset: fa350eb6 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/fa350eb62100d95aaf600008c5b5a9a9f0fdeb2b Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod 8347937: Canvas pattern test fails and crashes on WebKit 620.1 Reviewed-by: jpereda Backport-of: fd099a7f067c1694c1c12a8fa02b1e7eda51201f ------------- PR: https://git.openjdk.org/jfx17u/pull/250 From jpereda at openjdk.org Mon Jan 26 12:52:31 2026 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 26 Jan 2026 12:52:31 GMT Subject: [jfx21u] Integrated: 8376299: [jfx21u] backported test requires more recent JDK In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 11:57:31 GMT, Jose Pereda wrote: > This PR removes the AutoCloseable feature from a test, as it is not supported by the min build and target JDK 17 that is set for JavaFX 21u. This pull request has now been integrated. Changeset: 8b4f8a48 Author: Jose Pereda URL: https://git.openjdk.org/jfx21u/commit/8b4f8a48ad6649e2e39a45baa310eafa6da176db Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8376299: [jfx21u] backported test requires more recent JDK Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx21u/pull/111 From angorya at openjdk.org Mon Jan 26 16:33:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 26 Jan 2026 16:33:38 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 218: > 216: for (int i = (startPos == -1 ? 0 : startPos); i < orderedChildren.size(); i++) { > 217: NGNode child = orderedChildren.get(i); > 218: child.render(g); more on the concurrency here: if one would instrument the get(int) method in `children` like so private final List children = new ArrayList<>(1) { public NGNode get(int ix) { System.out.println(Thread.currentThread()); return super.get(ix); } }; the log will show accesses from two threads: Thread[#33,JavaFX Application Thread,5,main] ... Thread[#28,QuantumRenderer-0,5,main] ... Thread[#33,JavaFX Application Thread,5,main] The access pattern for `viewOrderChildren` seem to show only QuantumRenderer thread, though I did not test extensively. Does anyone know if these two threads are allowed to run in parallel, or is there a mechanism in place that ensures mutual exclusion? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2728325064 From kcr at openjdk.org Mon Jan 26 17:20:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Jan 2026 17:20:46 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 16:30:50 GMT, Andy Goryachev wrote: >> Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused imports > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 218: > >> 216: for (int i = (startPos == -1 ? 0 : startPos); i < orderedChildren.size(); i++) { >> 217: NGNode child = orderedChildren.get(i); >> 218: child.render(g); > > more on the concurrency here: if one would instrument the get(int) method in `children` like so > > > private final List children = new ArrayList<>(1) { > public NGNode get(int ix) { > System.out.println(Thread.currentThread()); > return super.get(ix); > } > }; > > > the log will show accesses from two threads: > > > Thread[#33,JavaFX Application Thread,5,main] > ... > Thread[#28,QuantumRenderer-0,5,main] > ... > Thread[#33,JavaFX Application Thread,5,main] > > > The access pattern for `viewOrderChildren` seem to show only QuantumRenderer thread, though I did not test extensively. > > Does anyone know if these two threads are allowed to run in parallel, or is there a mechanism in place that ensures mutual exclusion? Yes, this is expected. No, the threads do not run in parallel. The renderLock mechanism prevents it. The only access from the JavaFX Application thread is while holding the render lock to update the render graph (NG* nodes) from the scene graph. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2728511729 From angorya at openjdk.org Mon Jan 26 17:56:32 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 26 Jan 2026 17:56:32 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports given the clarification provided by @kevinrushforth (thanks!), it seems we can safely remove the try-catch block and the comment about concurrent access. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2043#pullrequestreview-3707254540 From mstrauss at openjdk.org Mon Jan 26 18:53:58 2026 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 26 Jan 2026 18:53:58 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 17:17:44 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java line 218: >> >>> 216: for (int i = (startPos == -1 ? 0 : startPos); i < orderedChildren.size(); i++) { >>> 217: NGNode child = orderedChildren.get(i); >>> 218: child.render(g); >> >> more on the concurrency here: if one would instrument the get(int) method in `children` like so >> >> >> private final List children = new ArrayList<>(1) { >> public NGNode get(int ix) { >> System.out.println(Thread.currentThread()); >> return super.get(ix); >> } >> }; >> >> >> the log will show accesses from two threads: >> >> >> Thread[#33,JavaFX Application Thread,5,main] >> ... >> Thread[#28,QuantumRenderer-0,5,main] >> ... >> Thread[#33,JavaFX Application Thread,5,main] >> >> >> The access pattern for `viewOrderChildren` seem to show only QuantumRenderer thread, though I did not test extensively. >> >> Does anyone know if these two threads are allowed to run in parallel, or is there a mechanism in place that ensures mutual exclusion? > > Yes, this is expected. No, the threads do not run in parallel. The renderLock mechanism prevents it. The only access from the JavaFX Application thread is while holding the render lock to update the render graph (NG* nodes) from the scene graph. A bit unrelated, but what does the "NG" in "NGNode" stand for? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2728827941 From andy.goryachev at oracle.com Mon Jan 26 20:15:45 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 26 Jan 2026 20:15:45 +0000 Subject: [External] : Re: Default event handlers In-Reply-To: <19689dff-2fda-4161-b094-cd5c91cd3b3b@gmail.com> References: <25F300A5-2523-4750-AD1F-78EC92533DDC@gmail.com> <2a66679a-7e6a-4aeb-9adf-68c13e96d172@gmail.com> <78B73FC1-C64E-4BEE-9779-2E5E6D48488D@gmail.com> <19689dff-2fda-4161-b094-cd5c91cd3b3b@gmail.com> Message-ID: > If we want InputMaps I think InputMap provides substantial value. I also agree about addressing the Skin/Behavior split. In fact, I see InputMap as an entity that ties the three parts together: - Control provides a fa?ade - Skin provides the visual representation - Behavior encapsulates event handlers - InputMap maintains the pointers to the event handlers and resolves the priority issues between application and skin event handlers. I've been trying to advance an InputMap implementation [0], which I think helps application, skin, and custom component developers alike, while also solving the priority issue and opening up the behavior customization a bit. There are two POC - one is being incubated as a part of the rich text area in incubator.input module, the other is a partial implementation using a subset of somewhat complicated controls [1]. We went through a series of prolonged discussions. Among the sticky points were: - desire to have static behaviors, for the purpose of allowing the application to customize the behavior or all the controls of the given type I guess - general dislike of having behavior classes inherit from a BaseBehavior convenience class I am sure there were more, so I think we should continue. I would like to see InputMap public API because it adds tremendous value without much cost. What do you think? -andy References [0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md [1] https://github.com/openjdk/jfx/pull/1495 From: John Hendrikx Date: Tuesday, January 13, 2026 at 13:44 To: Andy Goryachev , Martin Fox Cc: OpenJFX Subject: Re: [External] : Re: Default event handlers Hi, The InputMap is a user of the event system. It is basically a configurable event handler for a limited number of event types. You could write one right now, expose it, and configure mappings, and in fact, to save on event handlers, this is exactly how many handlers already work. Introducing it as an integral part of say Control immediately raises concerns; is InputMap going to be yet another event handler that users will have to fight when they install their own? At most I see this as part of a public Behavior API, where the Behavior can install (default) handlers, that then delegate to an accessible input map for that Behavior. Swing doesn't have a Control/Behavior/Skin split, but FX does, and I think we should remain committed to that instead of making some Swing/QT/Compose Frankenstein hybrid here by copying features without thinking about the bigger picture and how they really fit into FX. Furthermore, the current private InputMap implementation is, to put it midly, insanely inefficient, and so I find it incredibly hard to justify using even parts of that design. Everything in it is Observable, but nobody will be able to monitor it all for changes as that would entail installing hundreds of handlers for the average TextField input map. What's also inefficient is that this input map gets recreated for each control, leading to several kilobytes of overhead for every TextField in your application. There is just no reason to duplicate input maps like this as they're all going to be same 99.999% of the time. If we want InputMaps, then I think we need to solve the Skin/Behavior split first -- this alone will be a huge win for FX, as reskinning then becomes trivial, finally fulfilling the promise that FX has made for easily reskinnable controls, as you no longer lose the default platform behavior. Then with Behaviors also being replaceable, one can much easier allow for custom behaviors that expose fancy things like a fully customizable InputMap (although please, let's not make it observable, and let's de-duplicate them). --John On 13/01/2026 18:35, Andy Goryachev wrote: I agree with Martin that this issue is mostly limited to Controls because of the skins. What was the main objection to the InputMap idea I proposed? I do want to ask Martin one thing though: what do you mean by "The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it." Can you give an example? Thanks! -andy From: openjfx-dev on behalf of Martin Fox Date: Tuesday, January 13, 2026 at 09:00 To: John Hendrikx Cc: OpenJFX Subject: Re: [External] : Re: Default event handlers I didn?t intend to re-open all of these debates. I just wanted to point out that JavaFX in general uses dispatchers to process events so there?s no existing concept of default handlers outside of Control. If Control had implemented InputMap using a dispatcher we probably wouldn?t be having this conversation. I still believe this is a local problem for Control and it can craft its own solution. It doesn?t even have to involve handlers; look at how Scene and Menu handle accelerators. Whatever Control wants to do almost all of the tools are there. The only obvious gap in the public API is that there?s no way for a handler or filter to communicate with the dispatcher that invoked it. Rather than add a specialized bit like this PR does I thought it might be worth considering a more generalized solution (I can think of a few) but I?m actually fine with preventDefault() since it?s based on an existing standard. Martin On Jan 13, 2026, at 4:52?AM, John Hendrikx wrote: On 13/01/2026 00:43, Andy Goryachev wrote: The reason I mentioned #2 is that it is somewhat relevant to the discussion, as in "why do we need to write custom dispatchers at all?" There should be only two methods, in my opinion, one that dispatches an event that bubbles up (with filters and handlers), and one that sends an event to a single target Node and nothing else. Somehow, Swing got the Events right - it manages to dispatch one (1) event in total, and the dispatching stops once the event is consumed. The FX decided it needed to reinvent the wheel and leave multiple booby traps in the process. Although I agree that how FX solved events is sub-optimal, there is a real need here to communicate to the EventHandler on which object it resides. EventHandler instances are expensive when you need to attach one to every Cell in a TableView, and so to re-use a single instance, you need to know which Cell the event applies to. The source field (which is supposed to be constant) has been abused for this, making events non-constant requiring cloning before they can be dispatched to their final target. This cloning then caused the "isConsumed" problem. Perhaps we should just make the source field mutable as well, so the cloning isn't needed. The solution to this problem at the time should not have been to modify events, but to have made event handlers be BiConsumers, with the Event **and** Node being passed to the callback (and a "convenience" method that delegates to the BiConsumer variant that accepts only Consumer -- we may be able to still do this...) This isn't exactly rocket science, we should be able to figure something out. Maybe there is another option that will satisfy everyone? I think the issue isn't so much in event dispatching, but in the Skin/Behavior system itself. Skin/Behaviors in FX is like giving root access to every user on your system. Sure it is convenient that everyone can do whatever they want, and as long as everyone behaves, everything works great. However one malicious user can interfere with others or leave behind hooks that later come to bite you. Controls are HOSTS for Skins and Behaviors. Skins and Behaviors are clients. They should be restricted to a very specific subset of functionality that benefits the host and is predictable for the host: - Skins get ownership of the children list of the Control; while a Skin is installed, the host should not be allowed to make modifications - Skins can monitor properties for changes but this should never lead to a direct observable change on the main control that a subsequent installed listener may observe; in other words, listener order should be irrelevant for what the Skin does in order to share the listener infrastructure without interference. Skins are free to directly take action on the children (which they own exclusively), just not on the main control; such actions should instead be deferred, usually by requesting a layout (this is usually already the case, but it is good to make this explicit so we can decide what a Skin is doing is a bug or not). - Behaviors can react to events at the lowest precedence, and exclusively only take action when receiving an event; this means that blocking all events will automatically mean the Behavior no longer does anything, but also that selectively blocking events allows some control over Behaviors - Behaviors can co-modify properties on the Control, but this should be clearly documented; controls are free to restrict this set (ie. a Behavior has no business modifying the "wrapText" property, or things like layout properties -- most often they do their work through pseudo class changes and modifying the value a control represents). That should really be all that is needed for a functioning Skin/Behavior system; no need for root access. Of course, root access to the Control is a ship that has sailed a long time ago; but that doesn't mean we can't introduce a client API for Skins/Behaviors. All that really takes is passing an object to the Skin/Behavior when it is installed. This object is an interface with which the Skin/Behavior can do their work. Should they choose to not circumvent this API, and do all their work through this API, they can remove all their clean-up code, as the Control can now do this automatically. This will greatly simplify skins, and remove a whole avenue of potential bugs. All work done through this API can be monitored by the Control. The control can: - Track what is installed (for later clean-up) - Reject installation of listeners/handlers it doesn't want to expose - Ensure that event handlers are installed at lowest precedence. This can be kept internal, so many solutions are possible: separate lists, default event handlers (internal API), priorities, etc. Everything you'd expect a host Control to be able to do, including forcefully removing all traces of a previously installed Skin, and disallowing it further access should it attempt to use the API again after a new Skin is installed. That's however not a requirement; all we'd need is that interface, and encourage Skins/Behaviors to use it. Correctly behaved Skins/Behaviors then get all the benefits, and will stop interfering with user code. This means of course modifications to existing skins, but it is mostly in their registration logic (which I think we modified like 5 times already). The minimum API needed can be fairly small, and does not need to include accessors for every property and handler with some smart signatures. For example: > void addListener(Function supplier, Consumer subscriber) Allows installation of a listener by doing: api.addListener(Slider::minProperty, v -> { ... }); In this way we can isolate and track what Skins/Behaviors are doing, ensure they don't interfere with user operations on the Control and also ensure guaranteed clean-up (if they refrain from accessing the Control directly). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From zelmidaoui at openjdk.org Mon Jan 26 21:43:31 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Mon, 26 Jan 2026 21:43:31 GMT Subject: RFR: 8325564: ComboBox popup does not correctly resize after update when on display Message-ID: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. Tested with the test app in bug and MonkeyTester. ------------- Commit messages: - Merge branch 'openjdk:master' into 8325564.popupSize - Merge branch 'openjdk:master' into 8325564.popupSize - Fixed ComboBox popup size not changing after update. Changes: https://git.openjdk.org/jfx/pull/2052/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325564 Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2052.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2052/head:pull/2052 PR: https://git.openjdk.org/jfx/pull/2052 From zelmidaoui at openjdk.org Mon Jan 26 21:48:05 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Mon, 26 Jan 2026 21:48:05 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character Message-ID: Added "^" character to JavaFX virtual keyboard. ------------- Commit messages: - Merge branch 'openjdk:master' into 8274928.caretCharacter - Added "^" to virtual keyboard Changes: https://git.openjdk.org/jfx/pull/2053/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2053&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8274928 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2053.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2053/head:pull/2053 PR: https://git.openjdk.org/jfx/pull/2053 From nlisker at gmail.com Tue Jan 27 10:41:39 2026 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 27 Jan 2026 12:41:39 +0200 Subject: AnchorPane and border/padding Message-ID: Hi, I've encountered what I think is a bug in AnchorPane. When setting a border and/or padding, any added children will be laid out on top of them rather than computing the anchor points from them. The documentation states "If the anchor pane has a border and/or padding set, the offsets will be measured from the inside edge of those insets." The test program gives a different result: public class TestApplication extends Application { public static void main(String[] args) { launch(TestApplication.class, args); } @Override public void start(Stage primaryStage) throws Exception { var pane = new AnchorPane(); pane.setBorder(new Border(new BorderStroke(Color.BLUE, BorderStrokeStyle.SOLID, null, new BorderWidths(6)))); pane.setPadding(new Insets(10)); pane.setBackground(Background.fill(Color.grayRgb(256/4, 0.8))); pane.setMaxHeight(100); pane.setMaxWidth(100); pane.setMinHeight(100); pane.setMinWidth(100); Rectangle rect = new Rectangle(40, 40); rect.setFill(Color.AQUA); pane.getChildren().add(rect); primaryStage.setScene(new Scene(new BorderPane(pane), 300, 200)); primaryStage.show(); } } The rectangle comes out on top of the border and insets. When using TilePane, FlowPane, and HBox, these are respected. The closest issue I found is https://bugs.openjdk.org/browse/JDK-8090844. I would say that the documentation is correct and AnchorPane's behavior is wrong, but I find it odd that it hasn't come up until now. - Nir From duke at openjdk.org Tue Jan 27 13:21:42 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 27 Jan 2026 13:21:42 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Ok so I'm going to integrate this. The NGGroup blending implementation is definitely wrong though as it does not apply the blendingMode field value when rendering, but checks it to determine whether it needs blending. If anyone wants to investigate a follow-up to this, that is a good place to start ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3805182854 From duke at openjdk.org Tue Jan 27 13:24:07 2026 From: duke at openjdk.org (duke) Date: Tue, 27 Jan 2026 13:24:07 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:04:26 GMT, Christopher Schnick wrote: >> This should improve the code quality of the class while preserving its original workings > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports @crschnick Your change (at version e5637626d18205a1940e88b5aaab9bc1993733d5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2043#issuecomment-3805192683 From duke at openjdk.org Tue Jan 27 13:26:20 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 27 Jan 2026 13:26:20 GMT Subject: RFR: 8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none [v4] In-Reply-To: <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com> References: <7FhtIRUJx3zQ70vo4-4HHpjIN3j4I_yAD10YqH1Ztk4=.99eb6a9b-b2aa-46fa-b9d4-0e196d5254ab@github.com> Message-ID: On Tue, 13 Jan 2026 18:04:40 GMT, Christopher Schnick wrote: >> A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point > > Christopher Schnick has updated the pull request incrementally with one additional commit since the last revision: > > Add test So this is ready for review now with the test. I have searched the various error logs that people sent me about unrelated issues, and found that this NPE occured for at least 5 people that reported other issues. All of those were on macOS 26, so something probably changed in the input handling there. Maybe it's a weird edge case or some accessibility thing, but it it definitely occurs somehow. If someone with macos expertise wants to take a look at the root cause, then this can be fixed in a follow-up issue I guess. There is definitely something wrong in the input handling on macOS 26, I just can't pinpoint it yet ------------- PR Comment: https://git.openjdk.org/jfx/pull/2034#issuecomment-3805202589 From kcr at openjdk.org Tue Jan 27 13:41:18 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 27 Jan 2026 13:41:18 GMT Subject: RFR: 8375561: Class NGGroup is in need of some cleanup [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 18:51:17 GMT, Michael Strau? wrote: >> Yes, this is expected. No, the threads do not run in parallel. The renderLock mechanism prevents it. The only access from the JavaFX Application thread is while holding the render lock to update the render graph (NG* nodes) from the scene graph. > > A bit unrelated, but what does the "NG" in "NGNode" stand for? It originally stood for Newt Graphics, which was the render graph implementation that supported Prism. We used to have a PG (Platform Graphics) interface that was implemented by a long-since-defunct SG (Swing Graphics) render graph and then NG. Eventually, SG was dropped and then the PG interface removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2043#discussion_r2732063423 From duke at openjdk.org Tue Jan 27 15:34:46 2026 From: duke at openjdk.org (Christopher Schnick) Date: Tue, 27 Jan 2026 15:34:46 GMT Subject: Integrated: 8375561: Class NGGroup is in need of some cleanup In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 18:14:35 GMT, Christopher Schnick wrote: > This should improve the code quality of the class while preserving its original workings This pull request has now been integrated. Changeset: 3d3d9e35 Author: Christopher Schnick Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/3d3d9e35e9eeba902ed1ab3863873e29d401eb59 Stats: 107 lines in 1 file changed: 0 ins; 96 del; 11 mod 8375561: Class NGGroup is in need of some cleanup Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/2043 From andy.goryachev at oracle.com Tue Jan 27 16:32:47 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 27 Jan 2026 16:32:47 +0000 Subject: AnchorPane and border/padding In-Reply-To: References: Message-ID: Nir: I think the problem is that the AnchorPane fails to handle null constraints, see for example https://bugs.openjdk.org/browse/JDK-8350809 In your example, try setting non-null anchor, like so https://github.com/andy-goryachev-oracle/Test/blob/9796540833c2430bec8f5aca9584faa2ffb7cc7f/src/goryachev/bugs/AnchorPane_WithBorders.java#L24 -andy From: openjfx-dev on behalf of Nir Lisker Date: Tuesday, January 27, 2026 at 02:42 To: openjfx-dev Subject: AnchorPane and border/padding Hi, I've encountered what I think is a bug in AnchorPane. When setting a border and/or padding, any added children will be laid out on top of them rather than computing the anchor points from them. The documentation states "If the anchor pane has a border and/or padding set, the offsets will be measured from the inside edge of those insets." The test program gives a different result: public class TestApplication extends Application { public static void main(String[] args) { launch(TestApplication.class, args); } @Override public void start(Stage primaryStage) throws Exception { var pane = new AnchorPane(); pane.setBorder(new Border(new BorderStroke(Color.BLUE, BorderStrokeStyle.SOLID, null, new BorderWidths(6)))); pane.setPadding(new Insets(10)); pane.setBackground(Background.fill(Color.grayRgb(256/4, 0.8))); pane.setMaxHeight(100); pane.setMaxWidth(100); pane.setMinHeight(100); pane.setMinWidth(100); Rectangle rect = new Rectangle(40, 40); rect.setFill(Color.AQUA); pane.getChildren().add(rect); primaryStage.setScene(new Scene(new BorderPane(pane), 300, 200)); primaryStage.show(); } } The rectangle comes out on top of the border and insets. When using TilePane, FlowPane, and HBox, these are respected. The closest issue I found is https://bugs.openjdk.org/browse/JDK-8090844. I would say that the documentation is correct and AnchorPane's behavior is wrong, but I find it odd that it hasn't come up until now. - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jan 27 16:37:06 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 27 Jan 2026 16:37:06 +0000 Subject: AnchorPane and border/padding In-Reply-To: References: Message-ID: In other words, the case you are describing is not a bug, though we probably should document the behavior when no anchors are set on a child. -andy From: openjfx-dev on behalf of Andy Goryachev Date: Tuesday, January 27, 2026 at 08:33 To: Nir Lisker , openjfx-dev Subject: Re: AnchorPane and border/padding Nir: I think the problem is that the AnchorPane fails to handle null constraints, see for example https://bugs.openjdk.org/browse/JDK-8350809 In your example, try setting non-null anchor, like so https://github.com/andy-goryachev-oracle/Test/blob/9796540833c2430bec8f5aca9584faa2ffb7cc7f/src/goryachev/bugs/AnchorPane_WithBorders.java#L24 -andy From: openjfx-dev on behalf of Nir Lisker Date: Tuesday, January 27, 2026 at 02:42 To: openjfx-dev Subject: AnchorPane and border/padding Hi, I've encountered what I think is a bug in AnchorPane. When setting a border and/or padding, any added children will be laid out on top of them rather than computing the anchor points from them. The documentation states "If the anchor pane has a border and/or padding set, the offsets will be measured from the inside edge of those insets." The test program gives a different result: public class TestApplication extends Application { public static void main(String[] args) { launch(TestApplication.class, args); } @Override public void start(Stage primaryStage) throws Exception { var pane = new AnchorPane(); pane.setBorder(new Border(new BorderStroke(Color.BLUE, BorderStrokeStyle.SOLID, null, new BorderWidths(6)))); pane.setPadding(new Insets(10)); pane.setBackground(Background.fill(Color.grayRgb(256/4, 0.8))); pane.setMaxHeight(100); pane.setMaxWidth(100); pane.setMinHeight(100); pane.setMinWidth(100); Rectangle rect = new Rectangle(40, 40); rect.setFill(Color.AQUA); pane.getChildren().add(rect); primaryStage.setScene(new Scene(new BorderPane(pane), 300, 200)); primaryStage.show(); } } The rectangle comes out on top of the border and insets. When using TilePane, FlowPane, and HBox, these are respected. The closest issue I found is https://bugs.openjdk.org/browse/JDK-8090844. I would say that the documentation is correct and AnchorPane's behavior is wrong, but I find it odd that it hasn't come up until now. - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Jan 27 18:21:31 2026 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 27 Jan 2026 20:21:31 +0200 Subject: AnchorPane and border/padding In-Reply-To: References: Message-ID: You're right that it's the null constraints. I would have expected them to still respect borders and padding. This definitely needs to be documented. On Tue, Jan 27, 2026 at 6:37?PM Andy Goryachev wrote: > > In other words, the case you are describing is not a bug, though we probably should document the behavior when no anchors are set on a child. > > -andy > > > From: openjfx-dev on behalf of Andy Goryachev > Date: Tuesday, January 27, 2026 at 08:33 > To: Nir Lisker , openjfx-dev > Subject: Re: AnchorPane and border/padding > > Nir: > > I think the problem is that the AnchorPane fails to handle null constraints, see for example https://bugs.openjdk.org/browse/JDK-8350809 > > In your example, try setting non-null anchor, like so > https://github.com/andy-goryachev-oracle/Test/blob/9796540833c2430bec8f5aca9584faa2ffb7cc7f/src/goryachev/bugs/AnchorPane_WithBorders.java#L24 > > -andy > > > > From: openjfx-dev on behalf of Nir Lisker > Date: Tuesday, January 27, 2026 at 02:42 > To: openjfx-dev > Subject: AnchorPane and border/padding > > Hi, > > I've encountered what I think is a bug in AnchorPane. When setting a > border and/or padding, any added children will be laid out on top of > them rather than computing the anchor points from them. The > documentation states "If the anchor pane has a border and/or padding > set, the offsets will be measured from the inside edge of those > insets." > > The test program gives a different result: > > public class TestApplication extends Application { > > public static void main(String[] args) { > launch(TestApplication.class, args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > var pane = new AnchorPane(); > pane.setBorder(new Border(new BorderStroke(Color.BLUE, > BorderStrokeStyle.SOLID, null, new BorderWidths(6)))); > pane.setPadding(new Insets(10)); > pane.setBackground(Background.fill(Color.grayRgb(256/4, 0.8))); > > pane.setMaxHeight(100); > pane.setMaxWidth(100); > pane.setMinHeight(100); > pane.setMinWidth(100); > > Rectangle rect = new Rectangle(40, 40); > rect.setFill(Color.AQUA); > pane.getChildren().add(rect); > > primaryStage.setScene(new Scene(new BorderPane(pane), 300, 200)); > primaryStage.show(); > } > } > > The rectangle comes out on top of the border and insets. When using > TilePane, FlowPane, and HBox, these are respected. The closest issue I > found is https://bugs.openjdk.org/browse/JDK-8090844. > > I would say that the documentation is correct and AnchorPane's > behavior is wrong, but I find it odd that it hasn't come up until now. > > - Nir From angorya at openjdk.org Tue Jan 27 18:42:38 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 18:42:38 GMT Subject: RFR: 8325564: ComboBox popup does not correctly resize after update when on display In-Reply-To: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> Message-ID: <-QioOhyFajYiSzhNjI2U6tZ0shdHYw7GUD_1abcs6wY=.0879dbf4-ae39-48e6-b66d-11816c24f327@github.com> On Mon, 26 Jan 2026 21:36:46 GMT, Ziad El Midaoui wrote: > Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. > Tested with the test app in bug and MonkeyTester. The fix does not look right: I don't think the new flag is needed, but instead the popup should be properly sized. On top of that, the fixed code does not work: the first update shows a tiny popup where most of the area is covered with scrollbars, and the second update (after 2 seconds) still displays scrollbars. The scrollbars should not be there at all: Image Image (on macOS retina, scale=2) there is more: on an external monitor at scale=1, if I press the [Update] button then quickly click on the combo box, the popup is shown but very small, and it does not change: Image modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 560: > 558: > 559: final Node popupContent = getPopupContent(); > 560: if (popupResize && popupContent instanceof Region) { minor stylistic suggestion: if (popupResize && popupContent instanceof Region r) { r.setMinSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE); r.setPrefSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE); } modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 594: > 592: } > 593: > 594: final void requestPopupLayout() { misnomer: the name suggests it's a request, but in fact it does much more by calling reconfigurePopup(); sizePopup(); ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2052#pullrequestreview-3712782266 PR Review Comment: https://git.openjdk.org/jfx/pull/2052#discussion_r2733288104 PR Review Comment: https://git.openjdk.org/jfx/pull/2052#discussion_r2733293716 From angorya at openjdk.org Tue Jan 27 18:42:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 18:42:39 GMT Subject: RFR: 8325564: ComboBox popup does not correctly resize after update when on display In-Reply-To: <-QioOhyFajYiSzhNjI2U6tZ0shdHYw7GUD_1abcs6wY=.0879dbf4-ae39-48e6-b66d-11816c24f327@github.com> References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> <-QioOhyFajYiSzhNjI2U6tZ0shdHYw7GUD_1abcs6wY=.0879dbf4-ae39-48e6-b66d-11816c24f327@github.com> Message-ID: On Tue, 27 Jan 2026 18:23:58 GMT, Andy Goryachev wrote: >> Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. >> Tested with the test app in bug and MonkeyTester. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java line 560: > >> 558: >> 559: final Node popupContent = getPopupContent(); >> 560: if (popupResize && popupContent instanceof Region) { > > minor stylistic suggestion: > > if (popupResize && popupContent instanceof Region r) { > r.setMinSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE); > r.setPrefSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE); > } also, look in `sizePopup()`, there is `if (popupContent instanceof Region) {` with the `else` clause which handles other cases. Should any possible fix be in `sizePopup()` instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2052#discussion_r2733314457 From andy.goryachev at oracle.com Tue Jan 27 18:44:51 2026 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 27 Jan 2026 18:44:51 +0000 Subject: [External] : Re: AnchorPane and border/padding In-Reply-To: References: Message-ID: I've updated https://bugs.openjdk.org/browse/JDK-8350809 since it seems related. Thanks! -andy From: Nir Lisker Date: Tuesday, January 27, 2026 at 10:22 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: AnchorPane and border/padding You're right that it's the null constraints. I would have expected them to still respect borders and padding. This definitely needs to be documented. On Tue, Jan 27, 2026 at 6:37?PM Andy Goryachev wrote: > > In other words, the case you are describing is not a bug, though we probably should document the behavior when no anchors are set on a child. > > -andy > > > From: openjfx-dev on behalf of Andy Goryachev > Date: Tuesday, January 27, 2026 at 08:33 > To: Nir Lisker , openjfx-dev > Subject: Re: AnchorPane and border/padding > > Nir: > > I think the problem is that the AnchorPane fails to handle null constraints, see for example https://bugs.openjdk.org/browse/JDK-8350809 > > In your example, try setting non-null anchor, like so > https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/9796540833c2430bec8f5aca9584faa2ffb7cc7f/src/goryachev/bugs/AnchorPane_WithBorders.java*L24__;Iw!!ACWV5N9M2RV99hQ!O2KtfC3vI7UcebSWAftl2R62sFBi4QOCMUPd-006BSEERW4dJcowGSx74Pt82gCVNmIgjbTJDfOuISrDf1Fb$ > > -andy > > > > From: openjfx-dev on behalf of Nir Lisker > Date: Tuesday, January 27, 2026 at 02:42 > To: openjfx-dev > Subject: AnchorPane and border/padding > > Hi, > > I've encountered what I think is a bug in AnchorPane. When setting a > border and/or padding, any added children will be laid out on top of > them rather than computing the anchor points from them. The > documentation states "If the anchor pane has a border and/or padding > set, the offsets will be measured from the inside edge of those > insets." > > The test program gives a different result: > > public class TestApplication extends Application { > > public static void main(String[] args) { > launch(TestApplication.class, args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > var pane = new AnchorPane(); > pane.setBorder(new Border(new BorderStroke(Color.BLUE, > BorderStrokeStyle.SOLID, null, new BorderWidths(6)))); > pane.setPadding(new Insets(10)); > pane.setBackground(Background.fill(Color.grayRgb(256/4, 0.8))); > > pane.setMaxHeight(100); > pane.setMaxWidth(100); > pane.setMinHeight(100); > pane.setMinWidth(100); > > Rectangle rect = new Rectangle(40, 40); > rect.setFill(Color.AQUA); > pane.getChildren().add(rect); > > primaryStage.setScene(new Scene(new BorderPane(pane), 300, 200)); > primaryStage.show(); > } > } > > The rectangle comes out on top of the border and insets. When using > TilePane, FlowPane, and HBox, these are respected. The closest issue I > found is https://bugs.openjdk.org/browse/JDK-8090844 . > > I would say that the documentation is correct and AnchorPane's > behavior is wrong, but I find it odd that it hasn't come up until now. > > - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jan 27 19:29:15 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 19:29:15 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character In-Reply-To: References: Message-ID: <1VjVzAwAU65vsnaU3SLmPGmD8DPIlgcEpkECiDpO_tg=.597b82d1-10bb-497e-806e-17d2ff1b74d6@github.com> On Mon, 26 Jan 2026 21:38:50 GMT, Ziad El Midaoui wrote: > Added "^" character to JavaFX virtual keyboard. To enable virtual keyboard, launch any app with `-Dcom.sun.javafx.virtualKeyboard=javafx` General comments about the virtual keyboard in general, unrelated to this fix: 1. on macOS the virtual keyboard is positioned behind the dock making bottom row keys inaccessible: Screenshot 2026-01-27 at 11 12 36 I don't know whether it's a problem or not. 2. It is totally unclear how to invoke alternative keys - turns out it's a long press gesture. The UI does not show which keys are alternative which I think is poor accessibility. Perhaps we ought to show the alternative keys? 3. Some symbols on the keyboard appear truncated: %, ?, ? etc., even when they are large. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3807091779 From angorya at openjdk.org Tue Jan 27 19:36:21 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 19:36:21 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:38:50 GMT, Ziad El Midaoui wrote: > Added "^" character to JavaFX virtual keyboard. modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/TextBoard.txt line 2: > 1: #removed unsupported ymacron, yhook > 2: [q|1|\[ ][w|2|\] ][e|3|{|egrave|eacute|ecirc|euml ][r|4|}|reg ][t|5|<|tm ][y|6|^|>|ygrave|yacute|ycirc|yuml ][u|7|laquo|ugrave|uacute|ucirc|uuml ][i|8|raquo|igrave|iacute|icirc|iuml ][o|9|`|ograve|oacute|ocirc|otilde|ouml|oslash|deg ][p|0|~|para|pi ] I think the order should be different, since `>` might be more frequently used than `^`. I don't have any data to support this statement though. Another reason is symmetry, since it is prettier to show `5<` and `6>` My suggestion is to move `^` after `>`: [y|6|>|^|ygrave|yacute|ycirc|yuml ] ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2053#discussion_r2733508700 From angorya at openjdk.org Tue Jan 27 19:39:48 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 19:39:48 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:38:50 GMT, Ziad El Midaoui wrote: > Added "^" character to JavaFX virtual keyboard. `` why L1005 does String boardFileName = type.substring(0,1).toUpperCase() + type.substring(1).toLowerCase() + "Board.txt"; when you can simply pass the resource name as is, e.g. "TextBoard.txt" L454. This way one can actually use grep to find where in the code the thing is used... `` ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3807140397 From angorya at openjdk.org Tue Jan 27 20:06:20 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 27 Jan 2026 20:06:20 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:38:50 GMT, Ziad El Midaoui wrote: > Added "^" character to JavaFX virtual keyboard. Should the missing character also be added to `EmailBoard.txt` and `UrlBoard.txt`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3807276440 From credmond at certak.com Wed Jan 28 03:50:32 2026 From: credmond at certak.com (Cormac Redmond) Date: Wed, 28 Jan 2026 03:50:32 +0000 Subject: SortedList, identical elements + re-arranging Message-ID: Hi, I have noticed a troublesome quirk with SortedList which causes unexpected re-positioning of elements in its list. This is a noticeable problem when you are, for example, sorting a TableView on a column and re-insert an identical element at the same index in the source list (i.e., nothings changing). E.g., if your goal is to refresh a single row, even when there's no difference in the underlying object, SortedList can still shift its place in its arrays and hence the row shifts visibly in the table. On large tables, this can be a huge jump, outside of view. This occurs when the sort column value shares the same value with other rows (i.e., in my code sample below, multiple people are aged 62 and sorting is by age). Sample below code and output below. The bit in green represents what I would expect on each subsequent printout, but the bit in red shows the random re-arrangement of elements. There's no need to include a full TableView example to show this. But I've included a small gif too, for example. ---- Source Initial ---- Person item [0]: Person[name=Bob, age=60, id=0] Person item [1]: Person[name=Alice, age=70, id=1] Person item [2]: Person[name=Diana, age=30, id=2] Person item [3]: Person[name=Frank1, age=62, id=3] Person item [4]: Person[name=Eve, age=62, id=4] Person item [5]: Person[name=Frank2, age=62, id=5] Person item [6]: Person[name=Jim, age=62, id=6] Person item [7]: Person[name=Ivy, age=62, id=7] Person item [8]: Person[name=Jack, age=53, id=8] ---- Sorted Initial (Subsequent Prints Should Match This, But Don't) ---- Person item [0]: Person[name=Diana, age=30, id=2] Person item [1]: Person[name=Jack, age=53, id=8] Person item [2]: Person[name=Bob, age=60, id=0] Person item [3]: Person[name=Frank1, age=62, id=3] Person item [4]: Person[name=Eve, age=62, id=4] Person item [5]: Person[name=Frank2, age=62, id=5] Person item [6]: Person[name=Jim, age=62, id=6] Person item [7]: Person[name=Ivy, age=62, id=7] Person item [8]: Person[name=Alice, age=70, id=1] ---- Sorted After Identical Replace Index 5 ---- Person item [0]: Person[name=Diana, age=30, id=2] Person item [1]: Person[name=Jack, age=53, id=8] Person item [2]: Person[name=Bob, age=60, id=0] Person item [3]: Person[name=Frank2, age=62, id=5] Person item [4]: Person[name=Frank1, age=62, id=3] Person item [5]: Person[name=Eve, age=62, id=4] Person item [6]: Person[name=Jim, age=62, id=6] Person item [7]: Person[name=Ivy, age=62, id=7] Person item [8]: Person[name=Alice, age=70, id=1] ---- Sorted After Identical Replace Index 4 ---- Person item [0]: Person[name=Diana, age=30, id=2] Person item [1]: Person[name=Jack, age=53, id=8] Person item [2]: Person[name=Bob, age=60, id=0] Person item [3]: Person[name=Eve, age=62, id=4] Person item [4]: Person[name=Frank2, age=62, id=5] Person item [5]: Person[name=Frank1, age=62, id=3] Person item [6]: Person[name=Jim, age=62, id=6] Person item [7]: Person[name=Ivy, age=62, id=7] Person item [8]: Person[name=Alice, age=70, id=1] ---- Sorted After Identical Replace Index 3 ---- Person item [0]: Person[name=Diana, age=30, id=2] Person item [1]: Person[name=Jack, age=53, id=8] Person item [2]: Person[name=Bob, age=60, id=0] Person item [3]: Person[name=Frank1, age=62, id=3] Person item [4]: Person[name=Eve, age=62, id=4] Person item [5]: Person[name=Frank2, age=62, id=5] Person item [6]: Person[name=Jim, age=62, id=6] Person item [7]: Person[name=Ivy, age=62, id=7] Person item [8]: Person[name=Alice, age=70, id=1] ...etc. Code: public class SortedListBehaviour { public static void main(String[] args) { ObservableList personList = FXCollections.observableArrayList(); personList.addAll( new Person("Bob", 60, 0), new Person("Alice", 70, 1), new Person("Diana", 30, 2), new Person("Frank1", 62, 3), new Person("Eve", 62, 4), new Person("Frank2", 62, 5), new Person("Jim", 62, 6), new Person("Ivy", 62, 7), new Person("Jack", 53, 8) ); SortedList sortedList = new SortedList<>(personList, Comparator.comparing(Person::age)); // Starting out printList(personList, "Source Initial"); // This is sorted by age, all subsequent prints should look like this, but they don't printList(sortedList, "Sorted Initial (Subsequent Prints Should Match This, But Don't)"); personList.set(5, new Person("Frank2", 62, 5)); // Replace with identical, at same index printList(sortedList, "Sorted After Identical Replace Index 5"); personList.set(4, new Person("Eve", 62, 4)); // Replace with identical, at same index printList(sortedList, "Sorted After Identical Replace Index 4"); personList.set(3, new Person("Frank1", 62, 3)); // Replace with identical, at same index printList(sortedList, "Sorted After Identical Replace Index 3"); } private static void printList(final List list, final String source) { System.out.println("\n---- " + source + " ----"); for (int i = 0; i < list.size(); i++) { final Person next = list.get(i); System.out.println("Person item [" + i + "]: " + next); } } public record Person(String name, int age, int id) { @Override public boolean equals(final Object o) { if (o == null || getClass() != o.getClass()) { return false; } final Person person = (Person) o; return id == person.id && age == person.age && Objects.equals(name, person.name); } @Override public int hashCode() { return Objects.hash(name, age, id); } } } UI example also; the "Refresh" item here replaces the object with an identical object and the same index, yet it will often jump around the table as you can see, and selection can change too. [image: sl.gif] I understand that strictly speaking the list is still sorted correctly (by age), but SortedList could make some effort to reduce re-arranging already-present elements. Regards, *Cormac Redmond* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.gif Type: image/gif Size: 58742 bytes Desc: not available URL: From aghaisas at openjdk.org Wed Jan 28 06:29:20 2026 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Wed, 28 Jan 2026 06:29:20 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS In-Reply-To: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> Message-ID: <-ls4N0hcEstnom49siDbMOcMxAF0yeo8tW7HHNlzl-U=.22b176ec-dee1-4f78-89a6-464611e4d9ed@github.com> On Fri, 23 Jan 2026 01:58:07 GMT, Ambarish Rapte wrote: > The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. > During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues. > Changing the pipeline to default early in jfx27 would offer more testing. > > If required one can always use es2 pipeline by passing `-Dprism.order=es2` Marked as reviewed by aghaisas (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2050#pullrequestreview-3714794163 From arapte at openjdk.org Wed Jan 28 08:04:41 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 28 Jan 2026 08:04:41 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS [v2] In-Reply-To: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> Message-ID: > The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. > During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues. > Changing the pipeline to default early in jfx27 would offer more testing. > > If required one can always use es2 pipeline by passing `-Dprism.order=es2` Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into mtl-default - default pipeline mtl ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2050/files - new: https://git.openjdk.org/jfx/pull/2050/files/189d752c..dfdefaef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2050&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2050&range=00-01 Stats: 111 lines in 2 files changed: 2 ins; 96 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/2050.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2050/head:pull/2050 PR: https://git.openjdk.org/jfx/pull/2050 From jbhaskar at openjdk.org Wed Jan 28 09:20:38 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 28 Jan 2026 09:20:38 GMT Subject: RFR: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Message-ID: Issue: JavaFX fails to build WebKit in DebugNative for [linux, macos] Solution: ASSERT(ec == TypeError) is incorrect for Java DOM API. createAttribute may throw InvalidCharacterError. Replaced ASSERT with if check and added debug logging for error code. ------------- Commit messages: - Merge branch 'debug623' - 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative - add delta for IntersectionRatio as All rect width height calculation is now in Float Changes: https://git.openjdk.org/jfx/pull/2054/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376282 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/2054.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2054/head:pull/2054 PR: https://git.openjdk.org/jfx/pull/2054 From jbhaskar at openjdk.org Wed Jan 28 09:34:20 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 28 Jan 2026 09:34:20 GMT Subject: Withdrawn: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative In-Reply-To: References: Message-ID: <5usqJjzrKsxFB6l76SMeXlto58cwq_Ys2JQ9L6Zc6xw=.0f6eb316-110b-4523-aed5-1ac65c69fec0@github.com> On Wed, 28 Jan 2026 09:13:13 GMT, Jay Bhaskar wrote: > Issue: JavaFX fails to build WebKit in DebugNative for [linux, macos] > Solution: ASSERT(ec == TypeError) is incorrect for Java DOM API. createAttribute may throw InvalidCharacterError. Replaced ASSERT with if check and added debug logging for error code. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/2054 From jbhaskar at openjdk.org Wed Jan 28 09:39:33 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 28 Jan 2026 09:39:33 GMT Subject: RFR: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Message-ID: Issue: JavaFX fails to build WebKit in DebugNative for [linux, macos] Solution: ASSERT(ec == TypeError) is incorrect for Java DOM API. createAttribute may throw InvalidCharacterError. Replaced ASSERT with if check and added debug logging for error code. ------------- Commit messages: - 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Changes: https://git.openjdk.org/jfx/pull/2055/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376282 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/2055.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2055/head:pull/2055 PR: https://git.openjdk.org/jfx/pull/2055 From jdv at openjdk.org Wed Jan 28 09:40:54 2026 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 28 Jan 2026 09:40:54 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS [v2] In-Reply-To: References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> Message-ID: On Wed, 28 Jan 2026 08:04:41 GMT, Ambarish Rapte wrote: >> The metal rendering pipeline was integrated in PR #1824, It has been well tested and ready for to be default pipeline on MacOS. >> During JavaFX 26 it was temporarily set as default for 6 weeks, during which we did not see any issues. >> Changing the pipeline to default early in jfx27 would offer more testing. >> >> If required one can always use es2 pipeline by passing `-Dprism.order=es2` > > Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into mtl-default > - default pipeline mtl Marked as reviewed by jdv (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2050#pullrequestreview-3715612155 From arapte at openjdk.org Wed Jan 28 10:31:04 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 28 Jan 2026 10:31:04 GMT Subject: RFR: 8373091: Make Metal the default JavaFX rendering pipeline for macOS [v2] In-Reply-To: References: <6ilQOYzKLlQeo2CtmIT0Qoy-NGy7wQ-XDMiUNgmtVkE=.d90b0cab-9f7e-4a3a-a51f-daedd379d8bb@github.com> Message-ID: On Fri, 23 Jan 2026 23:09:44 GMT, Kevin Rushforth wrote: > I presume you have (or will) run a CI headful test job? I triggered a job after your comment, no failures were observed. Thanks.. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2050#issuecomment-3810445013 From lkostyra at openjdk.org Wed Jan 28 11:08:12 2026 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 28 Jan 2026 11:08:12 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:49:27 GMT, Andy Goryachev wrote: >> The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. >> >> Improvements include: >> - syncing the toolbar with current character attributes >> - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) >> - paragraph format dialog, with the associated toolbar button and the main menu item >> >> Screenshot 2026-01-15 at 12 01 44 >> >> Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into 8373936.editor > - actions > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - whitespace > - whitespace > - Merge branch '8374035.insert.styles' into 8373936.editor > - 2026 > - Merge branch 'master' into 8374035.insert.styles > - ... and 27 more: https://git.openjdk.org/jfx/compare/422d3a95...df6dbb17 Looks good, runs good as well! I left one very minor nitpicky comment. apps/samples/RichTextAreaDemo/src/com/oracle/demo/richtext/editor/Actions.java line 493: > 491: return; > 492: } else if (start.equals(end)) { > 493: return; Minor: could technically merge this if-else block into one if (start == null || start.equals(end)) { return; } ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2026#pullrequestreview-3715970049 PR Review Comment: https://git.openjdk.org/jfx/pull/2026#discussion_r2736020929 From zelmidaoui at openjdk.org Wed Jan 28 12:11:36 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 28 Jan 2026 12:11:36 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character [v2] In-Reply-To: References: Message-ID: > Added "^" character to JavaFX virtual keyboard. Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: Added character to EmailBoard.txt and UrlBoard.txt ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2053/files - new: https://git.openjdk.org/jfx/pull/2053/files/86eaec05..3470966e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2053&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2053&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2053.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2053/head:pull/2053 PR: https://git.openjdk.org/jfx/pull/2053 From zelmidaoui at openjdk.org Wed Jan 28 12:11:39 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 28 Jan 2026 12:11:39 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 20:04:01 GMT, Andy Goryachev wrote: > Should the missing character also be added to `EmailBoard.txt` and `UrlBoard.txt`? Yes, I have added it ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3810939043 From zelmidaoui at openjdk.org Wed Jan 28 12:16:07 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 28 Jan 2026 12:16:07 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 12:11:36 GMT, Ziad El Midaoui wrote: >> Added "^" character to JavaFX virtual keyboard. > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Added character to EmailBoard.txt and UrlBoard.txt > General comments about the virtual keyboard in general, unrelated to this fix: > > 1. on macOS the virtual keyboard is positioned behind the dock making bottom row keys inaccessible: > I don't know whether it's a problem or not. Same issue with the dock positioned on the left or right side, I guess it needs a bug for it ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3810964795 From kcr at openjdk.org Wed Jan 28 16:52:49 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 16:52:49 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. This will need a CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3812490659 From angorya at openjdk.org Wed Jan 28 16:58:48 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 16:58:48 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. This probably needs 3 reviewers instead of 2. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3812540148 From kcr at openjdk.org Wed Jan 28 17:52:57 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 17:52:57 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 Message-ID: This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. ------------- Commit messages: - 8376601: Bump minimum JDK version for JavaFX to JDK 25 Changes: https://git.openjdk.org/jfx/pull/2056/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376601 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/2056.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2056/head:pull/2056 PR: https://git.openjdk.org/jfx/pull/2056 From angorya at openjdk.org Wed Jan 28 18:02:42 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 18:02:42 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 In-Reply-To: References: Message-ID: <3gyligbiBeq8hDKQuDfOQBnCG-9byCEV__ys2IizNQE=.f115ea30-fcba-4817-8f88-af49738a311c@github.com> On Wed, 28 Jan 2026 17:47:45 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. > > This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. build.properties line 93: > 91: jfx.build.jdk.version=25.0.1 > 92: jfx.build.jdk.buildnum=8 > 93: jfx.build.jdk.version.min=25 is `jfx.build.jdk.buildnum.min` correct or is it too early to update? build.properties line 98: > 96: > 97: # The jfx.gradle.version property defines the version of gradle that is > 98: # used in the build. It must match the version number in I assume the gradle version remains the same? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2056#discussion_r2737845572 PR Review Comment: https://git.openjdk.org/jfx/pull/2056#discussion_r2737847524 From kcr at openjdk.org Wed Jan 28 18:17:56 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 18:17:56 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: References: Message-ID: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. > > This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Bump minimum gradle version ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2056/files - new: https://git.openjdk.org/jfx/pull/2056/files/767b1530..1b79dfa3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2056&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2056&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/2056.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2056/head:pull/2056 PR: https://git.openjdk.org/jfx/pull/2056 From kcr at openjdk.org Wed Jan 28 18:17:59 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 18:17:59 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: <3gyligbiBeq8hDKQuDfOQBnCG-9byCEV__ys2IizNQE=.f115ea30-fcba-4817-8f88-af49738a311c@github.com> References: <3gyligbiBeq8hDKQuDfOQBnCG-9byCEV__ys2IizNQE=.f115ea30-fcba-4817-8f88-af49738a311c@github.com> Message-ID: On Wed, 28 Jan 2026 17:58:54 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Bump minimum gradle version > > build.properties line 93: > >> 91: jfx.build.jdk.version=25.0.1 >> 92: jfx.build.jdk.buildnum=8 >> 93: jfx.build.jdk.version.min=25 > > is `jfx.build.jdk.buildnum.min` correct or is it too early to update? Yes, I checked, and it is correct for JDK 25 as well. > build.properties line 98: > >> 96: >> 97: # The jfx.gradle.version property defines the version of gradle that is >> 98: # used in the build. It must match the version number in > > I assume the gradle version remains the same? The version we use, 9.2.0, remains the same. However, the minimum version needed to build with JDK 25 is 9.1.0. I'll update the minimum. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2056#discussion_r2737904040 PR Review Comment: https://git.openjdk.org/jfx/pull/2056#discussion_r2737905152 From angorya at openjdk.org Wed Jan 28 19:23:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 19:23:28 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> References: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> Message-ID: <7gNJ70Q9BFrJZcluGFJnXwfBRO9mdGgRNCMW31wSy2I=.7157e617-025d-48bf-98da-ce23c8f17587@github.com> On Wed, 28 Jan 2026 18:17:56 GMT, Kevin Rushforth wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. >> >> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. >> >> This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Bump minimum gradle version builds after upgrading gradle to 9.3.0 and openjdk to 25.0.2 on macOS. no changes to GHA I presume, since it runs? what about CI? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2056#pullrequestreview-3718640212 PR Comment: https://git.openjdk.org/jfx/pull/2056#issuecomment-3813388460 From zelmidaoui at openjdk.org Wed Jan 28 19:35:30 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 28 Jan 2026 19:35:30 GMT Subject: RFR: 8325564: ComboBox popup does not correctly resize after update when on display [v2] In-Reply-To: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> Message-ID: > Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. > Tested with the test app in bug and MonkeyTester. Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: Removed 'popupResize' flag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2052/files - new: https://git.openjdk.org/jfx/pull/2052/files/cfb00a44..c975fc59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=00-01 Stats: 22 lines in 2 files changed: 4 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/2052.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2052/head:pull/2052 PR: https://git.openjdk.org/jfx/pull/2052 From zelmidaoui at openjdk.org Wed Jan 28 20:08:03 2026 From: zelmidaoui at openjdk.org (Ziad El Midaoui) Date: Wed, 28 Jan 2026 20:08:03 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v4] In-Reply-To: References: Message-ID: <1279RLGXOR39R3SgAKDE_573RX34mGJ0NdAZ4CIRGbQ=.be25e0bf-4f0e-4158-95e3-c23ecfca1bd8@github.com> On Wed, 21 Jan 2026 19:49:27 GMT, Andy Goryachev wrote: >> The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. >> >> Improvements include: >> - syncing the toolbar with current character attributes >> - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) >> - paragraph format dialog, with the associated toolbar button and the main menu item >> >> Screenshot 2026-01-15 at 12 01 44 >> >> Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into 8373936.editor > - actions > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - whitespace > - whitespace > - Merge branch '8374035.insert.styles' into 8373936.editor > - 2026 > - Merge branch 'master' into 8374035.insert.styles > - ... and 27 more: https://git.openjdk.org/jfx/compare/422d3a95...df6dbb17 Tested and works fine as expected! LGTM ------------- Marked as reviewed by zelmidaoui (Committer). PR Review: https://git.openjdk.org/jfx/pull/2026#pullrequestreview-3718912457 From angorya at openjdk.org Wed Jan 28 20:16:02 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 20:16:02 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v4] In-Reply-To: References: Message-ID: <5ZNSE7FP6D9gdW3NyAAVBnb7si06bjJ3YcVqwjth1Go=.f0fb71d8-1fc2-48e1-addd-0a4ee39ba0f0@github.com> On Wed, 28 Jan 2026 11:04:37 GMT, Lukasz Kostyra wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into 8373936.editor >> - actions >> - Merge branch 'master' into 8373936.editor >> - Merge branch 'master' into 8373936.editor >> - Merge branch 'master' into 8373936.editor >> - whitespace >> - whitespace >> - Merge branch '8374035.insert.styles' into 8373936.editor >> - 2026 >> - Merge branch 'master' into 8374035.insert.styles >> - ... and 27 more: https://git.openjdk.org/jfx/compare/422d3a95...df6dbb17 > > Looks good, runs good as well! I left one very minor nitpicky comment. Thank you @lukostyra and @Ziad-Mid for reviewing! > apps/samples/RichTextAreaDemo/src/com/oracle/demo/richtext/editor/Actions.java line 493: > >> 491: return; >> 492: } else if (start.equals(end)) { >> 493: return; > > Minor: could technically merge this if-else block into one > > > if (start == null || start.equals(end)) { > return; > } you are right, but sometimes keeping things on separate lines helps when stepping through in a debugger. with your permission, I'll keep it as is since it's just a demo app. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2026#issuecomment-3813676275 PR Review Comment: https://git.openjdk.org/jfx/pull/2026#discussion_r2738428084 From angorya at openjdk.org Wed Jan 28 20:16:03 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 20:16:03 GMT Subject: Integrated: 8373936: RichEditorDemoApp enhancements In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 17:37:26 GMT, Andy Goryachev wrote: > The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. > > Improvements include: > - syncing the toolbar with current character attributes > - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) > - paragraph format dialog, with the associated toolbar button and the main menu item > > Screenshot 2026-01-15 at 12 01 44 > > Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): > - type something > - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux > - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold > - type something and confirm that inserted text is bold > the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. This pull request has now been integrated. Changeset: 744d7fa3 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/744d7fa3c9a69542924043802db6422bce2e184d Stats: 1323 lines in 12 files changed: 846 ins; 349 del; 128 mod 8373936: RichEditorDemoApp enhancements 8376138: RichTextArea: getModelStyleAttrs might return wrong attributes Reviewed-by: lkostyra, zelmidaoui ------------- PR: https://git.openjdk.org/jfx/pull/2026 From kcr at openjdk.org Wed Jan 28 20:41:02 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 20:41:02 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: <7gNJ70Q9BFrJZcluGFJnXwfBRO9mdGgRNCMW31wSy2I=.7157e617-025d-48bf-98da-ce23c8f17587@github.com> References: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> <7gNJ70Q9BFrJZcluGFJnXwfBRO9mdGgRNCMW31wSy2I=.7157e617-025d-48bf-98da-ce23c8f17587@github.com> Message-ID: On Wed, 28 Jan 2026 19:21:02 GMT, Andy Goryachev wrote: > no changes to GHA I presume, since it runs? what about CI? This PR doesn't change which JDK we use to build JavaFX with, either when running GHA tests or our CI. At some point we'll start using JDK 26 -- after JDK 26 GA and once we have a version of gradle that supports it -- but that's not what we're doing here. What is does is change is the target JDK release, and thus the _minimum_ JDK. I did a CI build to make sure that it still builds when using the new minimum. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2056#issuecomment-3813818461 From jvos at openjdk.org Wed Jan 28 20:49:06 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 28 Jan 2026 20:49:06 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> References: <2uhDUIFluk2D73c1gxWxUbE_NLhl5cb11nx8rkDsRHM=.8e0b65c2-8ffe-48f7-a66c-85b970e418c1@github.com> Message-ID: On Wed, 28 Jan 2026 18:17:56 GMT, Kevin Rushforth wrote: >> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. >> >> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. >> >> This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. >> >> This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Bump minimum gradle version Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/2056#pullrequestreview-3719075314 From jvos at openjdk.org Wed Jan 28 20:49:08 2026 From: jvos at openjdk.org (Johan Vos) Date: Wed, 28 Jan 2026 20:49:08 GMT Subject: RFR: 8376601: Bump minimum JDK version for JavaFX to JDK 25 [v2] In-Reply-To: References: <3gyligbiBeq8hDKQuDfOQBnCG-9byCEV__ys2IizNQE=.f115ea30-fcba-4817-8f88-af49738a311c@github.com> Message-ID: On Wed, 28 Jan 2026 18:14:48 GMT, Kevin Rushforth wrote: >> build.properties line 98: >> >>> 96: >>> 97: # The jfx.gradle.version property defines the version of gradle that is >>> 98: # used in the build. It must match the version number in >> >> I assume the gradle version remains the same? > > The version we use, 9.2.0, remains the same. However, the minimum version needed to build with JDK 25 is 9.1.0. I'll update the minimum. I'm not sure that change need to be part of this PR, as by itself gradle has nothing to do with the JavaFX codebase. But of course I understand it is needed to have a correct minimum gradle version if you use gradle to build the java source files, so I'm ok with it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2056#discussion_r2738538047 From kcr at openjdk.org Wed Jan 28 20:56:37 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 20:56:37 GMT Subject: RFR: 8373936: RichEditorDemoApp enhancements [v4] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:49:27 GMT, Andy Goryachev wrote: >> The goal of this work is to deliver a sufficiently complete implementation of an editor application based on the RichTextArea that users can adopt as is or use as, or use it as a foundation for a more complex editor. >> >> Improvements include: >> - syncing the toolbar with current character attributes >> - improved toolbar behavior in regards to character attributes, utilizing the new 'insertStyles' property [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035) >> - paragraph format dialog, with the associated toolbar button and the main menu item >> >> Screenshot 2026-01-15 at 12 01 44 >> >> Test case related to [JDK-8374035](https://bugs.openjdk.org/browse/JDK-8374035): >> - type something >> - place cursor at the middle of the typed text and hit command-B or ctrl-B on Win/Linux >> - notice how the formatting toolbar highlights [b] button indicating that the style for next character to be inserted has changed to bold >> - type something and confirm that inserted text is bold >> the new style is captured only in the toolbar UI, so clicking on some other part of the text reverts the bold button to the unselected state. > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into 8373936.editor > - actions > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - Merge branch 'master' into 8373936.editor > - whitespace > - whitespace > - Merge branch '8374035.insert.styles' into 8373936.editor > - 2026 > - Merge branch 'master' into 8374035.insert.styles > - ... and 27 more: https://git.openjdk.org/jfx/compare/422d3a95...df6dbb17 This seems a good candidate to backport to JavaFX 26. I note that the Enhancement is a demo-only change, which is effectively a test-only change, since we don't ship sample binaries, so it will need no approval beyond the code review to backport it to the `jfx26` branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2026#issuecomment-3813877255 From martinfox656 at gmail.com Wed Jan 28 21:15:57 2026 From: martinfox656 at gmail.com (Martin Fox) Date: Wed, 28 Jan 2026 13:15:57 -0800 Subject: Translucent window backdrops for stages Message-ID: I?ve submitted a PR (#2048) for enabling system backdrops in JavaFX windows. This allows JavaFX to tap into the translucent window backgrounds common on macOS and Windows 11. Since these effects require real-time blurring of the content behind the window they can only be rendered by the platform; JavaFX then alpha composites its content on top. My goal was to come up with a useful set of backdrops which exhibit similar behavior across platforms. For example, all of the backdrops respond to the window?s color scheme preference when determining their dominant color and consistently obey accessibility settings like reduceTransparency. I was not trying to support platform-specific backdrops like Glass on macOS 26. I don?t think Glass Regular is intended for top-level windows and Glass Clear is a special effect that only makes sense for something like the dock. (I also have some questions about the longevity of these effects. The UNIFIED stage style is defunct for a reason; glass and brushed metal window backgrounds don?t age well.) The PR doesn?t support Linux. Blurred window backgrounds have been kicking around on Linux for some time but there hasn?t been a standardized API for requesting them. Wayland has just started the process of standardizing a background effect extension protocol and I have no idea what the deployment schedule might be. The PR doesn?t support Windows 10. On that platform we need to program to a lower-level API and implement the entire backdrop effect ourselves responding to all the necessary window state changes and platform accessibility preferences. That API also requires a custom ViewPainter and altering Prism to deliver pixels to the window through a new path. The testing footprint for this would be large. These backdrops cover the entire window which limits their utility for transparent stages. If you style, say, a menu with rounded corners and a drop shadow and then try to place a backdrop behind it the backdrop will extend behind the shadow and ignore the corner rounding. I think this is an inherent limitation. Even on a platform like macOS where we can shape the backdrop it would be tricky to align a shaped backdrop drawn by the platform with edge effects drawn by JavaFX (though to be honest I haven?t prototyped this). Unfortunately this means we can?t support the obvious use case of adding a translucent backdrop to a CSS-styled menu that uses a drop shadow. I?m open to suggestions on how this feature should interact with CSS. Initially I thought that a stylesheet should be able to specify a backdrop but currently the CSS code only targets nodes for styling. It was also suggested that there should be media queries related to backdrops but I?m not sure what those would be. The end result is a simple API which allows a developer to choose one of three backdrops for a stage. This needs to be expanded to future-proof it but before that can happen we need to sort out top-level issues like whether Win10 support is required, whether we need to support platform specific backdrops like glass on macOS, and how backdrops should interact with CSS. Thoughts, questions, and feedback welcome. Martin From angorya at openjdk.org Wed Jan 28 22:59:35 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 22:59:35 GMT Subject: [jfx26] RFR: 8373936: RichEditorDemoApp enhancements Message-ID: Backport of the following change: [JDK-8376138](https://bugs.openjdk.org/browse/JDK-8376138) RichTextArea: getModelStyleAttrs might return wrong attributes ------------- Commit messages: - Backport 744d7fa3c9a69542924043802db6422bce2e184d Changes: https://git.openjdk.org/jfx/pull/2057/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373936 Stats: 1323 lines in 12 files changed: 846 ins; 349 del; 128 mod Patch: https://git.openjdk.org/jfx/pull/2057.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2057/head:pull/2057 PR: https://git.openjdk.org/jfx/pull/2057 From kcr at openjdk.org Wed Jan 28 23:37:28 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 28 Jan 2026 23:37:28 GMT Subject: [jfx26] RFR: 8373936: RichEditorDemoApp enhancements In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 22:51:47 GMT, Andy Goryachev wrote: > Backport of the following change: > > [JDK-8376138](https://bugs.openjdk.org/browse/JDK-8376138) RichTextArea: getModelStyleAttrs might return wrong attributes LGTM. And Skara confirms that it is a clean backport. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2057#pullrequestreview-3719674814 From angorya at openjdk.org Wed Jan 28 23:44:39 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 28 Jan 2026 23:44:39 GMT Subject: [jfx26] Integrated: 8373936: RichEditorDemoApp enhancements In-Reply-To: References: Message-ID: <8z9ugAgL0mTGo7EA6Q012dr3WQYFL1IXea6M2WqAbyA=.cd2ab48e-cfb2-4556-9042-b0c9391731b2@github.com> On Wed, 28 Jan 2026 22:51:47 GMT, Andy Goryachev wrote: > Backport of the following change: > > [JDK-8376138](https://bugs.openjdk.org/browse/JDK-8376138) RichTextArea: getModelStyleAttrs might return wrong attributes This pull request has now been integrated. Changeset: 3c82487e Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/3c82487effbb7b8e1bc007749cb10dc57dfde7bb Stats: 1323 lines in 12 files changed: 846 ins; 349 del; 128 mod 8373936: RichEditorDemoApp enhancements 8376138: RichTextArea: getModelStyleAttrs might return wrong attributes Reviewed-by: kcr Backport-of: 744d7fa3c9a69542924043802db6422bce2e184d ------------- PR: https://git.openjdk.org/jfx/pull/2057 From arapte at openjdk.org Thu Jan 29 09:32:27 2026 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 29 Jan 2026 09:32:27 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 12:15:38 GMT, Christopher Schnick wrote: >> The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. >> >> If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. >> >> I tested this fix manually on Windows with a reproducer and it works as expected there > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments > - Improve positioning lgtm+ ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2044#pullrequestreview-3721581002 From duke at openjdk.org Thu Jan 29 10:03:56 2026 From: duke at openjdk.org (duke) Date: Thu, 29 Jan 2026 10:03:56 GMT Subject: RFR: 8338145: ComboBox popup is in wrong location on first showing [v3] In-Reply-To: References: Message-ID: <-hw_M-YnLGTtRQq9xsMqfleHr1Cf30YxeQSOR1OGobU=.493a2835-c526-411d-aa7f-19516d4f6392@github.com> On Wed, 21 Jan 2026 12:15:38 GMT, Christopher Schnick wrote: >> The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. >> >> If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. >> >> I tested this fix manually on Windows with a reproducer and it works as expected there > > Christopher Schnick has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments > - Improve positioning @crschnick Your change (at version c9f33f355b6ae5fa1d4043cd3cb1b8aa428540cf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2044#issuecomment-3816640702 From daniel.peintner at gmail.com Thu Jan 29 10:09:59 2026 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 29 Jan 2026 11:09:59 +0100 Subject: SortedList, identical elements + re-arranging In-Reply-To: References: Message-ID: Hi, I had and still have the same problem in a similar situation. The situation is as follows. A table contains a list of entries. A user selects an entry and performs a copy and paste operation (in order to modify the entry later). In this situation, the copied entry is identical by nature (Comparator returns 0). Even if I insert the *new* entry into the underlying list after the existing entry, SortedList decides to display the entry *before* the existing entry. This is confusing for a user. If there is a good solution for this, it would be helpful. However, I agree with Cormac Redmond that, ideally, the order should not change if the Comparator returns 0 (zero). Thanks, -- Daniel On Wed, Jan 28, 2026 at 4:51?AM Cormac Redmond wrote: > Hi, > > I have noticed a troublesome quirk with SortedList which causes unexpected > re-positioning of elements in its list. > > This is a noticeable problem when you are, for example, sorting a > TableView on a column and re-insert an identical element at the same index > in the source list (i.e., nothings changing). E.g., if your goal is to > refresh a single row, even when there's no difference in the underlying > object, SortedList can still shift its place in its arrays and hence the > row shifts visibly in the table. On large tables, this can be a huge jump, > outside of view. This occurs when the sort column value shares the same > value with other rows (i.e., in my code sample below, multiple people are > aged 62 and sorting is by age). > > Sample below code and output below. The bit in green represents what I > would expect on each subsequent printout, but the bit in red shows the > random re-arrangement of elements. > > There's no need to include a full TableView example to show this. But I've > included a small gif too, for example. > > ---- Source Initial ---- > Person item [0]: Person[name=Bob, age=60, id=0] > Person item [1]: Person[name=Alice, age=70, id=1] > Person item [2]: Person[name=Diana, age=30, id=2] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Jack, age=53, id=8] > > ---- Sorted Initial (Subsequent Prints Should Match This, But Don't) ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 5 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank2, age=62, id=5] > Person item [4]: Person[name=Frank1, age=62, id=3] > Person item [5]: Person[name=Eve, age=62, id=4] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 4 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Eve, age=62, id=4] > Person item [4]: Person[name=Frank2, age=62, id=5] > Person item [5]: Person[name=Frank1, age=62, id=3] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 3 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ...etc. > > > Code: > public class SortedListBehaviour { > > public static void main(String[] args) { > > ObservableList personList = > FXCollections.observableArrayList(); > > personList.addAll( > new Person("Bob", 60, 0), > new Person("Alice", 70, 1), > new Person("Diana", 30, 2), > new Person("Frank1", 62, 3), > new Person("Eve", 62, 4), > new Person("Frank2", 62, 5), > new Person("Jim", 62, 6), > new Person("Ivy", 62, 7), > new Person("Jack", 53, 8) > ); > > SortedList sortedList = new SortedList<>(personList, > Comparator.comparing(Person::age)); > > // Starting out > printList(personList, "Source Initial"); > > // This is sorted by age, all subsequent prints should look like > this, but they don't > printList(sortedList, "Sorted Initial (Subsequent Prints Should > Match This, But Don't)"); > > personList.set(5, new Person("Frank2", 62, 5)); // Replace with > identical, at same index > printList(sortedList, "Sorted After Identical Replace Index 5"); > > personList.set(4, new Person("Eve", 62, 4)); // Replace with > identical, at same index > printList(sortedList, "Sorted After Identical Replace Index 4"); > > personList.set(3, new Person("Frank1", 62, 3)); // Replace with > identical, at same index > printList(sortedList, "Sorted After Identical Replace Index 3"); > } > > private static void printList(final List list, final String > source) { > System.out.println("\n---- " + source + " ----"); > for (int i = 0; i < list.size(); i++) { > final Person next = list.get(i); > System.out.println("Person item [" + i + "]: " + next); > } > } > > public record Person(String name, int age, int id) { > @Override > public boolean equals(final Object o) { > if (o == null || getClass() != o.getClass()) { > return false; > } > final Person person = (Person) o; > return id == person.id && age == person.age && > Objects.equals(name, person.name); > } > > @Override > public int hashCode() { > return Objects.hash(name, age, id); > } > } > } > > > UI example also; the "Refresh" item here replaces the object with an > identical object and the same index, yet it will often jump around the > table as you can see, and selection can change too. > > [image: sl.gif] > > I understand that strictly speaking the list is still sorted correctly (by > age), but SortedList could make some effort to reduce re-arranging > already-present elements. > > > > Regards, > > *Cormac Redmond* > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.gif Type: image/gif Size: 58742 bytes Desc: not available URL: From lukasz.kostyra at oracle.com Thu Jan 29 11:02:26 2026 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Thu, 29 Jan 2026 11:02:26 +0000 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled? That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis. As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed. For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line. I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter. Let me know if KickstartFX runs properly with PresentingPainter. -Lukasz From: Christopher Schnick Sent: Wednesday, 21 January 2026 13:54 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu) On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations. You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install On 21/01/2026 13:48, Lukasz Kostyra wrote: Thanks for checking. I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine. I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :) -Lukasz From: Christopher Schnick Sent: Tuesday, 20 January 2026 16:24 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release In our main application I am getting the following error spammed in the logs: 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) 16:18:08:572 - error: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. On 20/01/2026 15:40, Lukasz Kostyra wrote: Hi Christopher, After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. Regards, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Wednesday, 10 December 2025 13:29 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release It should work fine without the property. Thanks for your help, I?ll keep searching. -Lukasz From: Christopher Schnick > Sent: Tuesday, 9 December 2025 17:10 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. Or should I still pass the property in this commit as well? On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: Hi Christopher, I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. Thanks, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Thursday, 4 December 2025 11:52 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. -Lukasz From: Christopher Schnick > Sent: Wednesday, 3 December 2025 18:53 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: Hi Christopher, I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. Thanks, -Lukasz From: Christopher Schnick Sent: Friday, 28 November 2025 13:25 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I did not encounter the vanishing issue anymore with that build, so at least it is usable. However, the font rendering issue still exists for some nodes: [cid:image001.png at 01DC9115.0E407BC0] It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. On 28/11/2025 12:41, Lukasz Kostyra wrote: Hi Christopher, I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Monday, 17 November 2025 15:14 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it. On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. -Lukasz From: Christopher Schnick > Sent: Saturday, 15 November 2025 17:39 To: Lukasz Kostyra > Cc: OpenJFX > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release Forgot to add, there is nothing out of the ordinary printed in the verbose logs. If I find the time, I can look into compiling a debug build. But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. On 15/11/2025 17:34, Christopher Schnick wrote: Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: [cid:image002.png at 01DC9115.0E407BC0] Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. On 13/11/2025 16:30, Lukasz Kostyra wrote: Thanks for checking. It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. Good luck! - Lukasz From: Christopher Schnick Sent: Thursday, 13 November 2025 16:11 To: Lukasz Kostyra Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. There is no exception thrown as far as I can see, so not sure what you need for debugging. For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx On 13/11/2025 14:40, Lukasz Kostyra wrote: Hello openjfx-dev, The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/ Please test this bundle and share your feedback by: - emailing openjfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. 3. It is recommended to use JDK 25 or later. 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. 5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Lukasz Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: image002.png URL: From crschnick at xpipe.io Thu Jan 29 12:30:58 2026 From: crschnick at xpipe.io (Christopher Schnick) Date: Thu, 29 Jan 2026 13:30:58 +0100 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking? The good news is that https://bugs.openjdk.org/browse/JDK-8154847?should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged. On 29/01/2026 12:02, Lukasz Kostyra wrote: > > I looked through KickstartFX and I noticed there?s a point where > KickstartFX forces the use of Uploading Painter - PlatformState.java @ > 112. UploadingPainter was designed to work with software pipeline as a > fallback mechanism (SW does not have the SwapChain/Presentation > mechanisms that HW pipelines use) so using it with > hardware-accelerated pipelines is not officially supported. When I set > prism.forceUploadingPainter to false text and buttons rendered > correctly with D3D12 on my machine. Could you check if everything > works fine on your end with UploadingPainter disabled? > > That being said, I do agree there should technically be no visual > difference between PresentingPainter and UploadingPainter. I have some > theories as to why that would be the case, but because > UploadingPainter with hardware pipelines is not officially supported > I?ll have to push this issue towards a later point in time. > UploadingPainter makes this a bit extra difficult to debug because > graphics debuggers rely on applications calling Present() to determine > when the application progresses to the next frame - with > UploadingPainter no Present() is called and debuggers can?t capture > the frame properly for analysis. > > As for Hyper-V problems - I didn?t get a chance to test these yet but > we also did not try running JavaFX with D3D12 backend on virtualized > platforms. I will take a look at that use case also at a later point > in time, once the performance improvements are completed. > > For both of these (UploadingPainter issues and Hyper-V issues) I?ll > add separate bugs to my backlog and tackle them later down the line. > > I also checked why UploadingPainter was preferred in KickstartFX and > this seems to be the issue - > https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned > in comment history is correct, there?s a possibility that with D3D12 > there should be no transparency issues, as D3D12 defaults to > alpha-supported SwapChain buffer (BGRX format exists but presents some > technical issues and limitations, BGRA is more convenient). However I > had no way of verifying this theory, on my Intel Iris Xe laptop the > reproducer works as expected on both D3D and D3D12, with or without > UploadingPainter. > > Let me know if KickstartFX runs properly with PresentingPainter. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Wednesday, 21 January 2026 13:54 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > Alright, that is good to know. I also ran the d3d12 build in a Hyper-V > Windows 11 VM, which are known to cause issues. For example, this > issue happens in those VMs with StageStyle.UNIFIED: > https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the > unified stage style unless you turn on performance mode in the > settings menu) > > On that system, the app sometimes froze completely, sometimes, the > rendered image got stuck. Changing the performance mode setting and > the property?-Dprism.forceUploadingPainter=true changed the behavior, > but it was broken in some way in all configurations. > > You should be able to reproduce these issues easily with the Windows > Sandbox feature: > https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install > > > On 21/01/2026 13:48, Lukasz Kostyra wrote: > > Thanks for checking. > > I ran the KickstartFX build one more time, it failed but I found > some leftover global gradle.properties file which defined older > JDK which broke the build. Changing JDK to 25.0.1 everything built > and works fine. > > I also found a way to build KickstartFX using custom JFX > (customJavaFxLibsPath in build.gradle) and can reproduce your font > issues locally on D3D12. I?ll report back when I solve them on my > end. :) > > -Lukasz > > *From:*Christopher Schnick > > *Sent:* Tuesday, 20 January 2026 16:24 > *To:* Lukasz Kostyra > > *Cc:* OpenJFX > > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > In our main application I am getting the following error spammed > in the logs: > > 16:18:08:571 - error: java.lang.NullPointerException: Cannot > invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:571 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > 16:18:08:572 - error:? ? ?at > javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) > 16:18:08:572 - error:? ? ?at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) > > In kickstartfx, I still get the font rendering issues. Can you > share the problems you encountered? I tried to build it on a blank > VM with git clone, setting a JDK25 in the PATH, and running > gradlew.bat run without issues. > > On 20/01/2026 15:40, Lukasz Kostyra wrote: > > Hi Christopher, > > After Christmas break I came back to this issue with some new > patches. There were some problems I found with the clear > optimization, I just submitted > https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 > > and according to my local testing everything seems to be fine now. > > When you have a moment, could you check out the changes above > and let me know if everything works correctly in your app? > > If there are still problems I would like to find a way to > build your app and test it locally. I tried doing that earlier > via https://github.com/xpipe-io/kickstartfx > > you linked earlier but encountered some problems when > building, so I?m going to need your help or some instructions > on how to build the app. > > Regards, > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of *Lukasz > Kostyra > *Sent:* Wednesday, 10 December 2025 13:29 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > It should work fine without the property. Thanks for your > help, I?ll keep searching. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Tuesday, 9 December 2025 17:10 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA release > > I tried this commit, but the problem shows up again. I tested > the previous commit with the passed property again, and that > one still works. > > Or should I still pass the property in this commit as well? > > On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I updated the direct3d12 branch with the fix - > https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 > > . Let me know how it works and if the problem has been > resolved. > > Thanks, > > -Lukasz > > *From:*openjfx-dev > *On Behalf Of > *Lukasz Kostyra > *Sent:* Thursday, 4 December 2025 11:52 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA release > > Thanks for checking. I filed > https://bugs.openjdk.org/browse/JDK-8373088 to track this > since this is unrelated to specifically text, will > probably get to it in a few days. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Wednesday, 3 December 2025 18:53 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* [External] : Re: JavaFX Direct3D 12 - Second EA > release > > This commit fixes the problem when the property is set to > false and it shows up again if the property is not set to > false > > On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: > > Hi Christopher, > > I did not find the way to reproduce this locally, but > I found a problem with one of the optimizations that > is in the backend. To double check if that is in fact > the issue I pushed > https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 > > to disable the optimization (it is on by default, > disabling it fixes that specific problem on my end) > and I?d like to double-check if this is the correct lead. > > When you have a moment, could you build JFX with that > change and run your app with > ?-Dprism.d3d12.clearOpts=false? added to the command line? > > If the problem persists with prism.d3d12.clearOpts set > to false I would need some more information on how > these labels are rendered to track this down. > > Thanks, > > -Lukasz > > *From:*Christopher Schnick > > *Sent:* Friday, 28 November 2025 13:25 > *To:* Lukasz Kostyra > > *Cc:* OpenJFX > > *Subject:* [External] : Re: JavaFX Direct3D 12 - > Second EA release > > I did not encounter the vanishing issue anymore with > that build, so at least it is usable. > > However, the font rendering issue still exists for > some nodes: > > It is not deterministic, meaning that if I just scroll > the scrollpane forward and back, the same text might > get rendered correctly. > > Also, did you see the performance results I posted for > my AMD system? Performance was quite bad there, so > this is not in a stage where I can test this in > production a bit. > > On 28/11/2025 12:41, Lukasz Kostyra wrote: > > Hi Christopher, > > I just pushed a fix for JDK-8371995 onto > direct3d12 branch in the sandbox - > https://github.com/openjdk/jfx-sandbox/tree/direct3d12 > > . If you find a moment, could you build JFX from > that branch and check if your app works correctly? > > -Lukasz > > *From:*openjfx-dev > *On Behalf > Of *Lukasz Kostyra > *Sent:* Monday, 17 November 2025 15:14 > *To:* Christopher Schnick > > *Cc:* OpenJFX > > *Subject:* RE: Re: JavaFX Direct3D 12 - Second EA > release > > I might?ve found the problem, there is an > assertion that triggers when multiple text objects > using different fonts are drawn. It could be > related (AFAIK Label controls will eventually end > up at the same text rendering routines as Text > nodes). Assertions are compiled out on Release for > performance, so there is a chance it would corrupt > the rendering without anything meaningful shown on > screen. > > To track this I just filed > https://bugs.openjdk.org/browse/JDK-8371995 . I > will check it and let you know when I fix it. > > On your side It might still be handy to build JFX > in DebugNative, to confirm if the triggered > assertion is the same and to later confirm if the > fix is working for you too. > > -Lukasz > > *From:*Christopher Schnick > *Sent:* Saturday, 15 November 2025 17:39 > *To:* Lukasz Kostyra > *Cc:* OpenJFX > *Subject:* Re: [External] : Re: JavaFX Direct3D 12 > - Second EA release > > Forgot to add, there is nothing out of the > ordinary printed in the verbose logs. > > If I find the time, I can look into compiling a > debug build. > > But the problem should be reproducible somehow > when just automatically creating a lot of labels > with random styles, sizes, and text. Some of them > should break as they did for me. > > On 15/11/2025 17:34, Christopher Schnick wrote: > > Ok, so I had more time to debug it. The one > weird thing I observed when it was working was > that some labels have corrupted text rendering: > > > Not all of them, most are fine. There are no > differences in terms of style classes etc. > between the labels. When scrolling, the > rendering sometimes switches between this > corrupted and normal state after some delay. > > After a while I also figured out that text > rendering is responsible for the issue of the > nodes vanishing: Certain label contents broke > the renderer. For example, in my application, > the string "Password manager" when assigned to > a label broke it and nothing was rendered > anymore. I tried to find an easy reproducer > but was not able to. It's probably very > dependent on all the different style classes > that influence the text shape/size/etc. > > On 13/11/2025 16:30, Lukasz Kostyra wrote: > > Thanks for checking. > > It is very possible the D3D12 runtime did > not like something, could be related to > your specific hardware. D3D12 by now has > many extensions which differ depending on > hardware and can lift certain restrictions > - we already internally had a case where > one GPU had some restriction that was not > enforced on another GPU and we had to > accommodate that. > > The first step would be to try running > D3D12 with ?-Dprism.verbose=true > -Dprism.debug=true?. These should print > additional logs that might have some extra > information. > > If there?s nothing useful there, next step > would be to build JavaFX with > -PCONF=DebugNative - this will compile > shaders in Debug, add assertions and debug > logs to the backend - and then run your > app with D3D12 debug layers and GPU > debugging enabled by adding > ?-Dprsim.d3d12.debugLayers=true > -Dprism.d3d12.gpuDebug=true?. Those will > slow down the app significantly, but will > also tell D3D12 to run additional API use > and GPU use checks. > > If the problem happens during a render > loop and debug layers catch it, there is a > chance it will cascade into other errors > and spam the console output - you can tell > D3D12 debug layers to trigger an assertion > on first encountered error with > ?-Dprism.d3d12.breakOnError=true?. > > I am running out of time today to check > this myself, but if you find something let > me know - I?ll try to reproduce the > problem myself and we?ll see where we go > from there. > > Good luck! > > - Lukasz > > *From:*Christopher Schnick > > > *Sent:* Thursday, 13 November 2025 16:11 > *To:* Lukasz Kostyra > > > *Cc:* openjfx-dev at openjdk.org > *Subject:* [External] : Re: JavaFX > Direct3D 12 - Second EA release > > I just tried to run a project with > provided jmods and at some point, certain > nodes are just not rendered anymore and > the window contents vanish. But they > render for a short period of time. > > There is no exception thrown as far as I > can see, so not sure what you need for > debugging. > > For testing, this is the built application > with the d3d12 jmods that you can use to > attempt to reproduce the problem: > https://we.tl/t-DJuX0BeqXm > > . It is built from these sources: > https://github.com/xpipe-io/kickstartfx > > > On 13/11/2025 14:40, Lukasz Kostyra wrote: > > Hello openjfx-dev, > > The second Early Access(EA) build of > JavaFX with the Windows Direct3D 12 > rendering pipeline is now available > at: > https://jdk.java.net/javafxdirect3d12/ > > > Please test this bundle and share your > feedback by: > > - emailing openjfx-dev at openjdk.java.net or > > - reporting issues via > JBS[https://bugs.openjdk.org/] or at > https://bugreport.java.com > > > This is the second EA release. The > backend is feature-complete and went > through a first optimization pass, but > it still requires some more testing on > more hardware variants before we can > consider it complete. As such, with > this release we also would like to > call for help with performance testing > the backend (more details on that will > be sent in a separate email thread). > > Known issues and pending tasks are > captured on JBS and can be accessed > using the filter provided on the > Direct3D 12 EA page > [https://jdk.java.net/javafxdirect3d12/ > ]. > Before reporting a new bug, please > review the existing issues to avoid > duplicates. > > Important Notes: > > 1. This is a Windows-specific feature, > so only a Windows-specific bundle is > provided. > > 2. The default rendering pipeline is > set to d3d12. Use "-Dprism.order=d3d" > or "-Dprism.order=sw" to select one of > the other pipelines for comparison > testing. > > 3. It is recommended to use JDK 25 or > later. > > 4. At this stage D3D12 backend is > feature-complete and went through the > first phase of optimization. It is > worth noting that, while generally we > noticed performance improvements, it > might not be on par with D3D backend > on every machine combo? - we already > noted performance being worse on > recent NVidia discrete GPUs > [https://bugs.openjdk.org/browse/JDK-8370486] > and are looking for solutions. > > 5. Issue behavior may vary across > different hardware, so please provide > detailed information, such as the > output of "java -Dprism.verbose=true" > or used hardware, when reporting or > discussing issues. > > 6. Refer: Run HelloWorld using JavaFX > SDK > [https://openjfx.io/openjfx-docs/#install-javafx > ] > > We look forward to your feedback. > > Regards, > > Lukasz > > Confidential- Oracle Internal > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: not available URL: From duke at openjdk.org Thu Jan 29 12:40:06 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 29 Jan 2026 12:40:06 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. Depending on how long this takes, would it be possible to extract the fix for the unified stage BackBufferFormat (if it actually fixes all cases) as a separate PR? That would make the review easier to split a feature addition and bugfix into two issues. I can definitely do the testing for the fix ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3817396967 From john.hendrikx at gmail.com Thu Jan 29 12:52:20 2026 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 29 Jan 2026 13:52:20 +0100 Subject: SortedList, identical elements + re-arranging In-Reply-To: References: Message-ID: <505b4879-fa1d-43fa-b364-83f6f57aaf30@gmail.com> The ListChangeBuilder implements set(int, T) as: publicvoidnextSet(intidx, E old) { nextRemove(idx, old); nextAdd(idx, idx + 1); } The Change interface?has a `wasReplaced` method which I think would be applicable for this case.??SortedList however does not check this case (it only checks add and remove), so it may be possible to make an adjusment inside SortedList to be smarter about how to handle this. --John On 28/01/2026 04:50, Cormac Redmond wrote: > Hi, > > I have noticed a troublesome quirk with SortedList which causes > unexpected re-positioning?of elements in its list. > > This is a noticeable?problem when you are, for example, sorting a > TableView on a column and re-insert an identical element at the same > index in the source list (i.e., nothings changing). E.g., if your goal > is to refresh a single row, even when there's no difference in the > underlying object, SortedList can still shift its place in its arrays > and hence the row shifts visibly in the table. On large tables, this > can be a huge jump, outside of view. This occurs when the sort column > value shares the same value with other?rows (i.e., in my code sample > below, multiple people are aged 62 and sorting is by age). > > Sample below code and output below. The bit in green represents what I > would expect on each subsequent printout, but the bit in red shows the > random re-arrangement of elements. > > There's no need to include a full TableView example to show this. But > I've included a small gif too, for example. > > ---- Source Initial ---- > Person item [0]: Person[name=Bob, age=60, id=0] > Person item [1]: Person[name=Alice, age=70, id=1] > Person item [2]: Person[name=Diana, age=30, id=2] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Jack, age=53, id=8] > > ---- Sorted Initial (Subsequent Prints Should Match This, But Don't) ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 5 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank2, age=62, id=5] > Person item [4]: Person[name=Frank1, age=62, id=3] > Person item [5]: Person[name=Eve, age=62, id=4] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 4 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Eve, age=62, id=4] > Person item [4]: Person[name=Frank2, age=62, id=5] > Person item [5]: Person[name=Frank1, age=62, id=3] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 3 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ...etc. > > > Code: > public class SortedListBehaviour { > > ? ? public static void main(String[] args) { > > ? ? ? ? ObservableList personList = > FXCollections.observableArrayList(); > > ? ? ? ? personList.addAll( > ? ? ? ? ? ? new Person("Bob", 60, 0), > ? ? ? ? ? ? new Person("Alice", 70, 1), > ? ? ? ? ? ? new Person("Diana", 30, 2), > ? ? ? ? ? ? new Person("Frank1", 62, 3), > ? ? ? ? ? ? new Person("Eve", 62, 4), > ? ? ? ? ? ? new Person("Frank2", 62, 5), > ? ? ? ? ? ? new Person("Jim", 62, 6), > ? ? ? ? ? ? new Person("Ivy", 62, 7), > ? ? ? ? ? ? new Person("Jack", 53, 8) > ? ? ? ? ); > > ? ? ? ? SortedList sortedList = new SortedList<>(personList, > Comparator.comparing(Person::age)); > > ? ? ? ? // Starting out > ? ? ? ? printList(personList, "Source Initial"); > > ? ? ? ? // This is sorted by age, all subsequent prints should look > like this, but they don't > ? ? ? ? printList(sortedList, "Sorted Initial (Subsequent Prints > Should Match This, But Don't)"); > > ? ? ? ? personList.set(5, new Person("Frank2", 62, 5)); // Replace > with identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace Index 5"); > > ? ? ? ? personList.set(4, new Person("Eve", 62, 4)); ?// Replace with > identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace Index 4"); > > ? ? ? ? personList.set(3, new Person("Frank1", 62, 3)); ?// Replace > with identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace Index 3"); > ? ? } > > ? ? private static void printList(final List list, final > String source) { > ? ? ? ? System.out.println("\n---- " + source + " ----"); > ? ? ? ? for (int i = 0; i < list.size(); i++) { > ? ? ? ? ? ? final Person next = list.get(i); > ? ? ? ? ? ? System.out.println("Person item [" + i + "]: " + next); > ? ? ? ? } > ? ? } > > ? ? public record Person(String name, int age, int id) { > ? ? ? ? @Override > ? ? ? ? public boolean equals(final Object o) { > ? ? ? ? ? ? if (o == null || getClass() != o.getClass()) { > ? ? ? ? ? ? ? ? return false; > ? ? ? ? ? ? } > ? ? ? ? ? ? final Person person = (Person) o; > ? ? ? ? ? ? return id == person.id && age == > person.age && Objects.equals(name, person.name ); > ? ? ? ? } > > ? ? ? ? @Override > ? ? ? ? public int hashCode() { > ? ? ? ? ? ? return Objects.hash(name, age, id); > ? ? ? ? } > ? ? } > } > > > UI example also; the "Refresh" item here replaces the object with an > identical object and the same index, yet it will often jump around the > table as you can see, and selection can change too. > > sl.gif > > I understand that strictly speaking the list is still sorted correctly > (by age), but SortedList could make some effort to reduce re-arranging > already-present elements. > > > > Regards, > * > * > *Cormac Redmond* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.gif Type: image/gif Size: 58742 bytes Desc: not available URL: From john.hendrikx at gmail.com Thu Jan 29 13:06:59 2026 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 29 Jan 2026 14:06:59 +0100 Subject: SortedList, identical elements + re-arranging In-Reply-To: References: Message-ID: <5bc1acb9-cdde-456c-8d09-d502cd41d155@gmail.com> Isn't this a different case? If I understood correctly, you expect a new entry to be added below an existing entry that happens to be equal? Basically, you expect the Table to act as a list sorted by index (you're inserting at a the current selected index + 1 in unsorted space) for copy/paste operations, while at the same time expecting the table to be sorted on some key that is not its index (and doesn't include the index in the comparator). So while the copy/paste indeed occurs below the existing entry (in index sorted view), the sorted view is completely unaware of this, and only sees a new entry. The SortedList could of course insert this new item after any existing items, but what if the user selected "insert before" or some such option?? Or what if the list was sorted in reverse?? Does that change where the paste ends up (above or below still)??? What if there are 5 rows with the same value, should it insert it after some "selected row" that it doesn't know about? The solution IMHO is to make this simply crystal clear in your Comparator.? If equal items should be ordered in insertion order, then the index should be part of the comparator.? Any decision that SortedList makes could be correct for some use cases, and incorrect for others. --John On 29/01/2026 11:09, Daniel Peintner wrote: > Hi, > > I had and still have the same problem in a similar situation. > > The situation is as follows. A table contains a list of entries. A > user selects an entry and performs a copy and paste operation (in > order to modify the entry later). > In this situation, the copied entry is identical by nature (Comparator > returns 0). > > Even if I insert the *new* entry into the underlying list after the > existing entry, SortedList decides to display the entry *before* the > existing entry. > > This is confusing for a user. > > If there is a good solution for this, it would be helpful. > However, I agree with Cormac Redmond that, ideally, the order should > not change if the Comparator returns 0 (zero). > > Thanks, > > -- Daniel > > > > On Wed, Jan 28, 2026 at 4:51?AM Cormac Redmond > wrote: > > Hi, > > I have noticed a troublesome quirk with SortedList which causes > unexpected re-positioning?of elements in its list. > > This is a noticeable?problem when you are, for example, sorting a > TableView on a column and re-insert an identical element at the > same index in the source list (i.e., nothings changing). E.g., if > your goal is to refresh a single row, even when there's no > difference in the underlying object, SortedList can still shift > its place in its arrays and hence the row shifts visibly in the > table. On large tables, this can be a huge jump, outside of view. > This occurs when the sort column value shares the same value with > other?rows (i.e., in my code sample below, multiple people are > aged 62 and sorting is by age). > > Sample below code and output below. The bit in green represents > what I would expect on each subsequent printout, but the bit in > red shows the random re-arrangement of elements. > > There's no need to include a full TableView example to show this. > But I've included a small gif too, for example. > > ---- Source Initial ---- > Person item [0]: Person[name=Bob, age=60, id=0] > Person item [1]: Person[name=Alice, age=70, id=1] > Person item [2]: Person[name=Diana, age=30, id=2] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Jack, age=53, id=8] > > ---- Sorted Initial (Subsequent Prints Should Match This, But > Don't) ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 5 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank2, age=62, id=5] > Person item [4]: Person[name=Frank1, age=62, id=3] > Person item [5]: Person[name=Eve, age=62, id=4] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 4 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Eve, age=62, id=4] > Person item [4]: Person[name=Frank2, age=62, id=5] > Person item [5]: Person[name=Frank1, age=62, id=3] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ---- Sorted After Identical Replace Index 3 ---- > Person item [0]: Person[name=Diana, age=30, id=2] > Person item [1]: Person[name=Jack, age=53, id=8] > Person item [2]: Person[name=Bob, age=60, id=0] > Person item [3]: Person[name=Frank1, age=62, id=3] > Person item [4]: Person[name=Eve, age=62, id=4] > Person item [5]: Person[name=Frank2, age=62, id=5] > Person item [6]: Person[name=Jim, age=62, id=6] > Person item [7]: Person[name=Ivy, age=62, id=7] > Person item [8]: Person[name=Alice, age=70, id=1] > > ...etc. > > > Code: > public class SortedListBehaviour { > > ? ? public static void main(String[] args) { > > ? ? ? ? ObservableList personList = > FXCollections.observableArrayList(); > > ? ? ? ? personList.addAll( > ? ? ? ? ? ? new Person("Bob", 60, 0), > ? ? ? ? ? ? new Person("Alice", 70, 1), > ? ? ? ? ? ? new Person("Diana", 30, 2), > ? ? ? ? ? ? new Person("Frank1", 62, 3), > ? ? ? ? ? ? new Person("Eve", 62, 4), > ? ? ? ? ? ? new Person("Frank2", 62, 5), > ? ? ? ? ? ? new Person("Jim", 62, 6), > ? ? ? ? ? ? new Person("Ivy", 62, 7), > ? ? ? ? ? ? new Person("Jack", 53, 8) > ? ? ? ? ); > > ? ? ? ? SortedList sortedList = new > SortedList<>(personList, Comparator.comparing(Person::age)); > > ? ? ? ? // Starting out > ? ? ? ? printList(personList, "Source Initial"); > > ? ? ? ? // This is sorted by age, all subsequent prints should > look like this, but they don't > ? ? ? ? printList(sortedList, "Sorted Initial (Subsequent Prints > Should Match This, But Don't)"); > > ? ? ? ? personList.set(5, new Person("Frank2", 62, 5)); // Replace > with identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace > Index 5"); > > ? ? ? ? personList.set(4, new Person("Eve", 62, 4)); ?// Replace > with identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace > Index 4"); > > ? ? ? ? personList.set(3, new Person("Frank1", 62, 3)); ?// > Replace with identical, at same index > ? ? ? ? printList(sortedList, "Sorted After Identical Replace > Index 3"); > ? ? } > > ? ? private static void printList(final List list, final > String source) { > ? ? ? ? System.out.println("\n---- " + source + " ----"); > ? ? ? ? for (int i = 0; i < list.size(); i++) { > ? ? ? ? ? ? final Person next = list.get(i); > ? ? ? ? ? ? System.out.println("Person item [" + i + "]: " + next); > ? ? ? ? } > ? ? } > > ? ? public record Person(String name, int age, int id) { > ? ? ? ? @Override > ? ? ? ? public boolean equals(final Object o) { > ? ? ? ? ? ? if (o == null || getClass() != o.getClass()) { > ? ? ? ? ? ? ? ? return false; > ? ? ? ? ? ? } > ? ? ? ? ? ? final Person person = (Person) o; > ? ? ? ? ? ? return id == person.id && age == > person.age && Objects.equals(name, person.name ); > ? ? ? ? } > > ? ? ? ? @Override > ? ? ? ? public int hashCode() { > ? ? ? ? ? ? return Objects.hash(name, age, id); > ? ? ? ? } > ? ? } > } > > > UI example also; the "Refresh" item here replaces the object with > an identical object and the same index, yet it will often jump > around the table as you can see, and selection can change too. > > sl.gif > > I understand that strictly speaking the list is still sorted > correctly (by age), but SortedList could make some effort to > reduce re-arranging already-present elements. > > > > Regards, > * > * > *Cormac Redmond* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sl.gif Type: image/gif Size: 58742 bytes Desc: not available URL: From lukasz.kostyra at oracle.com Thu Jan 29 13:37:31 2026 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Thu, 29 Jan 2026 13:37:31 +0000 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today? Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed. -Lukasz From: Christopher Schnick Sent: Thursday, 29 January 2026 13:31 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking? The good news is that https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged. On 29/01/2026 12:02, Lukasz Kostyra wrote: I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled? That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis. As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed. For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line. I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue - https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter. Let me know if KickstartFX runs properly with PresentingPainter. -Lukasz From: Christopher Schnick Sent: Wednesday, 21 January 2026 13:54 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu) On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations. You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install On 21/01/2026 13:48, Lukasz Kostyra wrote: Thanks for checking. I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine. I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :) -Lukasz From: Christopher Schnick Sent: Tuesday, 20 January 2026 16:24 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release In our main application I am getting the following error spammed in the logs: 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) 16:18:08:572 - error: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. On 20/01/2026 15:40, Lukasz Kostyra wrote: Hi Christopher, After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. Regards, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Wednesday, 10 December 2025 13:29 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release It should work fine without the property. Thanks for your help, I?ll keep searching. -Lukasz From: Christopher Schnick > Sent: Tuesday, 9 December 2025 17:10 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. Or should I still pass the property in this commit as well? On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: Hi Christopher, I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. Thanks, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Thursday, 4 December 2025 11:52 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. -Lukasz From: Christopher Schnick > Sent: Wednesday, 3 December 2025 18:53 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: Hi Christopher, I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. Thanks, -Lukasz From: Christopher Schnick Sent: Friday, 28 November 2025 13:25 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I did not encounter the vanishing issue anymore with that build, so at least it is usable. However, the font rendering issue still exists for some nodes: [cid:image001.png at 01DC912C.CB00AD40] It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. On 28/11/2025 12:41, Lukasz Kostyra wrote: Hi Christopher, I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Monday, 17 November 2025 15:14 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995 . I will check it and let you know when I fix it. On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. -Lukasz From: Christopher Schnick > Sent: Saturday, 15 November 2025 17:39 To: Lukasz Kostyra > Cc: OpenJFX > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release Forgot to add, there is nothing out of the ordinary printed in the verbose logs. If I find the time, I can look into compiling a debug build. But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. On 15/11/2025 17:34, Christopher Schnick wrote: Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: [cid:image002.png at 01DC912C.CB00AD40] Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. On 13/11/2025 16:30, Lukasz Kostyra wrote: Thanks for checking. It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. Good luck! - Lukasz From: Christopher Schnick Sent: Thursday, 13 November 2025 16:11 To: Lukasz Kostyra Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. There is no exception thrown as far as I can see, so not sure what you need for debugging. For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx On 13/11/2025 14:40, Lukasz Kostyra wrote: Hello openjfx-dev, The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at: https://jdk.java.net/javafxdirect3d12/ Please test this bundle and share your feedback by: - emailing openjfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. 3. It is recommended to use JDK 25 or later. 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. 5. Issue behavior may vary across different hardware, so please provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Lukasz Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18275 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 57114 bytes Desc: image002.png URL: From duke at openjdk.org Thu Jan 29 13:52:37 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 29 Jan 2026 13:52:37 GMT Subject: Integrated: 8338145: ComboBox popup is in wrong location on first showing In-Reply-To: References: Message-ID: <6A64aNeOD-0XNCtpev4ch7dT-jdgW1vvdpRQLnaI81I=.0564606c-d0cc-4caf-a3f0-96272bcac118@github.com> On Mon, 19 Jan 2026 11:37:20 GMT, Christopher Schnick wrote: > The resize method in the combo box skin does not take into account whether the popup was autofixed or not. This causes a wrong position if the content size is changed, which it often is on initial show. > > If anyone has a better idea how to actually determine whether a popup was autofixed, then I can improve the check. Currently it relies purely on the popup position and the combo box position. > > I tested this fix manually on Windows with a reproducer and it works as expected there This pull request has now been integrated. Changeset: 61702913 Author: Christopher Schnick Committer: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/61702913217205ec8dddcaf30d2469728767196e Stats: 16 lines in 1 file changed: 13 ins; 0 del; 3 mod 8338145: ComboBox popup is in wrong location on first showing Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/2044 From kcr at openjdk.org Thu Jan 29 14:01:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jan 2026 14:01:46 GMT Subject: RFR: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:31:56 GMT, Jay Bhaskar wrote: > Issue: JavaFX fails to build WebKit in DebugNative for [linux, macos] > Solution: ASSERT(ec == TypeError) is incorrect for Java DOM API. createAttribute may throw InvalidCharacterError. Replaced ASSERT with if check and added debug logging for error code. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/2055#pullrequestreview-3722914426 From jbhaskar at openjdk.org Thu Jan 29 14:06:53 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 29 Jan 2026 14:06:53 GMT Subject: Integrated: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:31:56 GMT, Jay Bhaskar wrote: > Issue: JavaFX fails to build WebKit in DebugNative for [linux, macos] > Solution: ASSERT(ec == TypeError) is incorrect for Java DOM API. createAttribute may throw InvalidCharacterError. Replaced ASSERT with if check and added debug logging for error code. This pull request has now been integrated. Changeset: 0f091426 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/0f091426eb44e7a11bf6c8d15a2359d8d7760da8 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/2055 From jbhaskar at openjdk.org Thu Jan 29 14:52:14 2026 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 29 Jan 2026 14:52:14 GMT Subject: [jfx26u] RFR: 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Message-ID: A clean backport for jfx26u. The patch fixes build issue in debug mode after webkit upgrade 623.1. The test fails without fix and passes with fix. ------------- Commit messages: - Backport 0f091426eb44e7a11bf6c8d15a2359d8d7760da8 Changes: https://git.openjdk.org/jfx26u/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx26u&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376282 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx26u/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx26u.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx26u/pull/5 From duke at openjdk.org Thu Jan 29 16:14:02 2026 From: duke at openjdk.org (youngledo) Date: Thu, 29 Jan 2026 16:14:02 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling [v2] In-Reply-To: References: Message-ID: <04p0NRxG3AmjXqWIVvmz6f8S3LX6m55v-nvGu9-asOc=.3fc1904d-9d5f-4f3f-a475-c271010270e1@github.com> > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: Message-ID: On Thu, 29 Jan 2026 14:45:25 GMT, Jay Bhaskar wrote: > A clean backport for jfx26u. The patch fixes build issue in debug mode after webkit upgrade 623.1. The test fails without fix and passes with fix. This pull request has now been integrated. Changeset: 24749d1c Author: Jay Bhaskar URL: https://git.openjdk.org/jfx26u/commit/24749d1c22b6b2d0a5b05b568c61d776e15c0baf Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod 8376282: [linux, macos] JavaFX fails to build WebKit in DebugNative Backport-of: 0f091426eb44e7a11bf6c8d15a2359d8d7760da8 ------------- PR: https://git.openjdk.org/jfx26u/pull/5 From mfox at openjdk.org Thu Jan 29 16:32:22 2026 From: mfox at openjdk.org (Martin Fox) Date: Thu, 29 Jan 2026 16:32:22 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:37:09 GMT, Christopher Schnick wrote: > Depending on how long this takes, would it be possible to extract the fix for the unified stage BackBufferFormat (if it actually fixes all cases) as a separate PR? It would probably be faster for you to test and submit the PR yourself. The fix is just the two lines in native-prism-d3d where the BackBufferFormat is set to D3DFMT_A8R8G8B8 instead of being left unspecified. Based on the write up for bug [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847) if you don't set the back buffer format what you get varies depending on the graphic card. It should be OK to enable alpha unconditionally, in the end it should only affect UNIFIED. Most stage styles wipe out the alpha channel by drawing an opaque background. The exceptions are TRANSPARENT and UNIFIED and only UNIFIED uses the swap chain. If you'd prefer I can enter the PR but it would probably have to wait until next week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3818789755 From duke at openjdk.org Thu Jan 29 16:32:23 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 29 Jan 2026 16:32:23 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: References: Message-ID: <2YykM0OlYMPAiTgmY7uRtLFtDL0kAt54MSE-_c6lZ3k=.ee295e9b-67c1-4cc6-96ab-cdde4749f84c@github.com> On Wed, 21 Jan 2026 20:15:16 GMT, Martin Fox wrote: > This PR enables translucent window backdrops for JavaFX stages on macOS and Windows 11. Since we?re reliant on the operating system for these effects (they typically require real-time blurring of the desktop) I needed to flesh out a fairly complete prototype to sort out the API. I will start a discussion about the API on the mailing list. > > There?s a crude manual test for trying out the different backdrop materials. > > java @build/run.args -Djavafx.enablePreview=true tests/manual/stage/BackdropTest.java > > You?ll want to drag the windows around to avoid having them overlap each other since they?re all created in the center of the screen. For windows without title bars you can click anywhere on the background to drag the window except for TRANSPARENT stages on Windows which are a bit tricker to get a hold of; try to click on a text label. > > If you create an UNDECORATED stage on Windows the backdrop won?t be translucent initially. This can be corrected by changing the stage?s color scheme. This is an OS bug that I haven?t found a workaround for. > > The changes on Windows 11 are minimal since we?re just invoking an OS feature by calling DwmSetWindowAttribute. I did need to make two small changes to the D3D9 Prism code to ensure that the swap chain and back buffer support an alpha channel so JavaFX can composite its content on top of the backdrop. This is the same way the old UNIFIED stage style worked before it became unreliable (see [JDK-8154847](https://bugs.openjdk.org/browse/JDK-8154847)). > > On macOS I moved the GlassHostView so it?s now a permanent part of the NSWindow. For some time the host view has been a remnant left over from an older approach to implementing fullscreen. Now it serves as a common parent for the NSVisualEffectView that provides the backdrop and the GlassView3D that contains the JavaFX content. Making it the permanent contentView of the NSWindow simplifies some code. > > To validate the API I did prototype this for Windows 10 (thanks @mstr2!). Well, I prototyped this using DirectComposition so it should work on Win10 but I can't test Win10 myself. Using DirectComposition is much more involved so I shelved that implementation for now but it does inform the API. It?s the reason the backdrop needs to be specified before the Java window is shown and the platform window created. Can I somehow attribute the PR authorship to you in skara? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3818800257 From kcr at openjdk.org Thu Jan 29 16:38:44 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jan 2026 16:38:44 GMT Subject: RFR: 8375578: Enable translucent window backdrops In-Reply-To: <2YykM0OlYMPAiTgmY7uRtLFtDL0kAt54MSE-_c6lZ3k=.ee295e9b-67c1-4cc6-96ab-cdde4749f84c@github.com> References: <2YykM0OlYMPAiTgmY7uRtLFtDL0kAt54MSE-_c6lZ3k=.ee295e9b-67c1-4cc6-96ab-cdde4749f84c@github.com> Message-ID: On Thu, 29 Jan 2026 16:29:09 GMT, Christopher Schnick wrote: > Can I somehow attribute the PR authorship to you in skara? Yes: `/contributor add @beldenfox` will do it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-3818858144 From duke at openjdk.org Thu Jan 29 16:41:47 2026 From: duke at openjdk.org (youngledo) Date: Thu, 29 Jan 2026 16:41:47 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling [v3] In-Reply-To: References: Message-ID: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: Message-ID: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: Message-ID: On Wed, 28 Jan 2026 12:11:36 GMT, Ziad El Midaoui wrote: >> Added "^" character to JavaFX virtual keyboard. > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Added character to EmailBoard.txt and UrlBoard.txt Looks good! To test various virtual keyboard types, one can use the latest monkey tester from https://github.com/andy-goryachev-oracle/MonkeyTest by launching with this command line property: `-Dcom.sun.javafx.virtualKeyboard=javafx` Image ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2053#pullrequestreview-3724041830 From angorya at openjdk.org Thu Jan 29 19:20:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Jan 2026 19:20:28 GMT Subject: RFR: 8274928: JavaFX virtual keyboard missing ^ character [v2] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 12:11:36 GMT, Ziad El Midaoui wrote: >> Added "^" character to JavaFX virtual keyboard. > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Added character to EmailBoard.txt and UrlBoard.txt Created [JDK-8376737](https://bugs.openjdk.org/browse/JDK-8376737) ? Virtual Keyboard Issues [JDK-8376739](https://bugs.openjdk.org/browse/JDK-8376739) Virtual Keyboard: display alternative symbols ------------- PR Comment: https://git.openjdk.org/jfx/pull/2053#issuecomment-3819768737 From angorya at openjdk.org Thu Jan 29 20:16:28 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 29 Jan 2026 20:16:28 GMT Subject: RFR: 8325564: ComboBox popup does not correctly resize after update when on display [v2] In-Reply-To: References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> Message-ID: On Wed, 28 Jan 2026 19:35:30 GMT, Ziad El Midaoui wrote: >> Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. >> Tested with the test app in bug and MonkeyTester. > > Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision: > > Removed 'popupResize' flag The last change is a step in the right direction. Three issues: 1. Please merge the latest master, there was a change in sizePopup() which makes your code fail to compile. In general, it's a good idea to merge the latest master if your PR is long going or there was a change in a related area. 2. The reproducer shows the popup in the body of the first `KeyFrame` via `comboBox.show();`. Once the popup is shown, the second background update does not resize the popup and you see the scrollbars. 3. If you remove the `comboBox.show();` line, the expectation is that the popup will not be shown, but it is, resulting in this: Image Also, I've noticed the size of the popup control in the step 2 changes (also present in the master branch, so I guess it's expected) @crschnick would you be able to review this PR? ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2052#pullrequestreview-3724798249 PR Comment: https://git.openjdk.org/jfx/pull/2052#issuecomment-3820062736 From martinfox656 at gmail.com Thu Jan 29 21:14:51 2026 From: martinfox656 at gmail.com (Martin Fox) Date: Thu, 29 Jan 2026 13:14:51 -0800 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> Message-ID: <48790173-8AFF-4F02-BECC-24C41632B64B@gmail.com> The fixes I added for JDK-8154847 were specific to the D3D9 code and would have to be reproduced in D3D12. All I did was ensure that both the swap chain and the device had their BackBufferFormat set to D3DFMT_A8R8G8B8. The old code left the BackBufferFormat unspecified and apparently that meant you could get different results on different graphics cards (according to the bug report). The D3D12 branch is very different. I see that the swap chain has the correct format set but the AlphaMode is set to Ignore. No idea if that?s relevant. Unfortunately I can?t run D3D12 to verify that UNIFIED or translucent backdrops work with D3D12. This makes me nervous because the D3D9 version relies on some magic; in addition to setting the BackBufferFormat there?s a call to DwmExtendFrameIntoClientArea over in glass that allows the swap chain to use its alpha channel. It seems to be triggering the logic in the OS that allowed the old Aero glass effect to work. I just assumed the same would apply to D3D12 but I?m beginning to wonder. > On 29/01/2026 12:02, Lukasz Kostyra wrote: > That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. For what it's worth: UploadingPainter is normally used with TRANSPARENT stages which are implemented as layered windows. The pixels are passed to GDI using UpdateLayeredWindow which explicitly supports an alpha channel. KickstartFX is using UploadingPainter with a non-layered window and expecting the alpha channel to work. I?m not sure the glass code was designed to ensure that; it seems to be working by accident. The bits are passed to GDI using SetDIBitsToDevice and the documentation says nothing about the alpa channel. I suspect this call is also dependent on the magic DwmExtendFrameIntoClientArea call to make the alpha channel to work. Martin P.S. Doesn?t the UploadingPainter work with hardware acceleration for TRANSPARENT stages on Windows? I thought it drew to a texture and then pulled the bits into RAM and sent them off to the View. > On Jan 29, 2026, at 5:37?AM, Lukasz Kostyra wrote: > > Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today? > > Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed. > > -Lukasz > > From: Christopher Schnick > Sent: Thursday, 29 January 2026 13:31 > To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking? > > The good news is that https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged. > > On 29/01/2026 12:02, Lukasz Kostyra wrote: > I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled? > > That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis. > > As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed. > > For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line. > > I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue -https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter. > > Let me know if KickstartFX runs properly with PresentingPainter. > > -Lukasz > > From: Christopher Schnick > Sent: Wednesday, 21 January 2026 13:54 > To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu) > > On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations. > > You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install > On 21/01/2026 13:48, Lukasz Kostyra wrote: > Thanks for checking. > > I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine. > > I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :) > > -Lukasz > > From: Christopher Schnick > Sent: Tuesday, 20 January 2026 16:24 > To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > In our main application I am getting the following error spammed in the logs: > > 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture (BaseGraphics.java:464) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture (BaseShaderGraphics.java:159) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent (NGImageView.java:123) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender (NGImageView.java:103) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip (NGNode.java:2279) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip (NGNode.java:2186) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip (NGNode.java:2213) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache (CacheFilter.java:682) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render (CacheFilter.java:586) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached (NGNode.java:2343) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2054) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip (NGNode.java:2279) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip (NGNode.java:2186) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip (NGNode.java:2213) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache (CacheFilter.java:682) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render (CacheFilter.java:586) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached (NGNode.java:2343) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2054) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent (NGGroup.java:266) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent (NGRegion.java:579) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender (NGNode.java:2063) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render (NGNode.java:1955) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint (ViewPainter.java:481) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl (ViewPainter.java:329) > 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run (UploadingPainter.java:143) > 16:18:08:572 - error: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) > 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) > 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) > > In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. > > On 20/01/2026 15:40, Lukasz Kostyra wrote: > Hi Christopher, > > After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. > > When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? > > If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. > > Regards, > -Lukasz > > From: openjfx-dev On Behalf Of Lukasz Kostyra > Sent: Wednesday, 10 December 2025 13:29 > To: Christopher Schnick > Cc: OpenJFX > Subject: RE: Re: JavaFX Direct3D 12 - Second EA release > > It should work fine without the property. Thanks for your help, I?ll keep searching. > > -Lukasz > > From: Christopher Schnick > > Sent: Tuesday, 9 December 2025 17:10 > To: Lukasz Kostyra > > Cc: OpenJFX > > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. > > Or should I still pass the property in this commit as well? > > On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: > Hi Christopher, > > I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. > > Thanks, > -Lukasz > > From: openjfx-dev On Behalf Of Lukasz Kostyra > Sent: Thursday, 4 December 2025 11:52 > To: Christopher Schnick > Cc: OpenJFX > Subject: RE: Re: JavaFX Direct3D 12 - Second EA release > > Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. > > -Lukasz > > From: Christopher Schnick > > Sent: Wednesday, 3 December 2025 18:53 > To: Lukasz Kostyra > > Cc: OpenJFX > > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false > > On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: > Hi Christopher, > > I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. > > When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? > > If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. > > Thanks, > -Lukasz > > From: Christopher Schnick > Sent: Friday, 28 November 2025 13:25 > To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > I did not encounter the vanishing issue anymore with that build, so at least it is usable. > > However, the font rendering issue still exists for some nodes: > > > > It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. > > Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. > > On 28/11/2025 12:41, Lukasz Kostyra wrote: > Hi Christopher, > > I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? > > -Lukasz > > From: openjfx-dev On Behalf Of Lukasz Kostyra > Sent: Monday, 17 November 2025 15:14 > To: Christopher Schnick > Cc: OpenJFX > Subject: RE: Re: JavaFX Direct3D 12 - Second EA release > > I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. > > To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995. I will check it and let you know when I fix it. > > On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. > > -Lukasz > > From: Christopher Schnick > > Sent: Saturday, 15 November 2025 17:39 > To: Lukasz Kostyra > > Cc: OpenJFX > > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release > > Forgot to add, there is nothing out of the ordinary printed in the verbose logs. > > If I find the time, I can look into compiling a debug build. > > But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. > > On 15/11/2025 17:34, Christopher Schnick wrote: > Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: > > > > > Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. > > After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. > > On 13/11/2025 16:30, Lukasz Kostyra wrote: > Thanks for checking. > > It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. > > The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. > > If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. > > If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. > > I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. > > Good luck! > - Lukasz > > From: Christopher Schnick > Sent: Thursday, 13 November 2025 16:11 > To: Lukasz Kostyra > Cc: openjfx-dev at openjdk.org > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release > > I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. > > There is no exception thrown as far as I can see, so not sure what you need for debugging. > > For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx > On 13/11/2025 14:40, Lukasz Kostyra wrote: > Hello openjfx-dev, > > The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at:https://jdk.java.net/javafxdirect3d12/ > > Please test this bundle and share your feedback by: > - emailing openjfx-dev at openjdk.java.net or > - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com > > This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). > > Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/ ]. Before reporting a new bug, please review the existing issues to avoid duplicates. > > Important Notes: > 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. > 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. > 3. It is recommended to use JDK 25 or later. > 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. > 5. Issue behavior may vary across different hardware, soplease provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. > 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx ] > > We look forward to your feedback. > > Regards, > Lukasz > > Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jan 29 21:18:04 2026 From: duke at openjdk.org (Christopher Schnick) Date: Thu, 29 Jan 2026 21:18:04 GMT Subject: RFR: 8154847: Rendering is incorrect or not visible with StageStyle.UNIFIED on some graphics cards Message-ID: The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8. If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong. This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable. Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms. The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems. The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM. You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason. You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare. ------------- Commit messages: - Set backbuffer format explicitly Changes: https://git.openjdk.org/jfx/pull/2058/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8154847 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/2058.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2058/head:pull/2058 PR: https://git.openjdk.org/jfx/pull/2058 From kcr at openjdk.org Thu Jan 29 22:20:14 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 29 Jan 2026 22:20:14 GMT Subject: Integrated: 8376601: Bump minimum JDK version for JavaFX to JDK 25 In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 17:47:45 GMT, Kevin Rushforth wrote: > This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 25. > > In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so. > > This continues our current practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (25 in this specific case), is untested. > > This PR targeted to master for JavaFX 27, and must not be backported to any earlier version. This needs a CSR and a release note. This pull request has now been integrated. Changeset: a69bc061 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/a69bc0615a5ed2ef050ccc3e10e0dbcdbc88278d Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8376601: Bump minimum JDK version for JavaFX to JDK 25 Reviewed-by: angorya, jvos ------------- PR: https://git.openjdk.org/jfx/pull/2056 From duke at openjdk.org Fri Jan 30 00:44:15 2026 From: duke at openjdk.org (youngledo) Date: Fri, 30 Jan 2026 00:44:15 GMT Subject: RFR: Fix VirtualFlow performance regression in ListView scrolling [v5] In-Reply-To: References: Message-ID: > The commit 1b12c8a490 introduced two performance issues in VirtualFlow: > > 1. Calling requestLayout() on all cells in the pile on every layout pass This causes unnecessary layout calculations for 50-100 recycled cells per frame during scrolling. > > 2. Using sheetChildren.removeAll(pile) which has O(n*m) time complexity This becomes extremely slow with large cell pools. > > These changes caused severe scrolling lag in ListView/TableView with many items (e.g., 100+ items, even less). The fix removes both problematic code blocks while preserving the getViewportBreadth() visibility change needed by TableRowSkinBase. > > Tested with ListView containing 1000 items - scrolling is now smooth again, matching JavaFX 24 performance. > > The sample project has been uploaded: > [demo-javafx.zip](https://github.com/user-attachments/files/24561207/demo-javafx.zip) > > My system environment is: > - Apple M1 > - macOS 26.2 > > Installed and used JDKs from the following vendors via SDKMAN: > - 25.0.1-graalce > - 25.0.1.fx-nik > - 25.0.1-tem > > Without exception, the lists are all somewhat laggy when scrolling. But if I downgrade the FX version to 24, only "25.0.1.fx-nik" still shows lag ? the other two are very smooth! > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"> > 4.0.0 > > com.example > demo-javafx > 1.0-SNAPSHOT > jar > > JavaFX ListView Demo > > > UTF-8 > 25 > 25 > 0.0.8 > > > > > > org.openjfx > javafx-controls > ${javafx.version} > > > > > org.openjfx > javafx-fxml > ${javafx.version} > > > > > > > > org.apache.maven.plugins References: <63ZJXKrsn5pvg5PxS0MRtisvBzkmo0-UgVQ58E6ivBU=.ae2e1d27-3b43-4c7d-801a-daec2392ae4e@github.com> Message-ID: > Fixed popup size not changing to show more items or less when changing the number of items in `ComboBox` by adding a `popupResize` variable which triggers a request layout when there is change in items list. > Tested with the test app in bug and MonkeyTester. Ziad El Midaoui has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into 8325564.popupSize - Removed 'popupResize' flag - Merge branch 'openjdk:master' into 8325564.popupSize - Merge branch 'openjdk:master' into 8325564.popupSize - Fixed ComboBox popup size not changing after update. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/2052/files - new: https://git.openjdk.org/jfx/pull/2052/files/c975fc59..29a4d177 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=2052&range=01-02 Stats: 1464 lines in 18 files changed: 867 ins; 445 del; 152 mod Patch: https://git.openjdk.org/jfx/pull/2052.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2052/head:pull/2052 PR: https://git.openjdk.org/jfx/pull/2052 From lukasz.kostyra at oracle.com Fri Jan 30 13:03:01 2026 From: lukasz.kostyra at oracle.com (Lukasz Kostyra) Date: Fri, 30 Jan 2026 13:03:01 +0000 Subject: JavaFX Direct3D 12 - Second EA release In-Reply-To: <48790173-8AFF-4F02-BECC-24C41632B64B@gmail.com> References: <0b5bcb4c-6a35-4fc2-af52-b6273a319a57@xpipe.io> <19ae5e36-42ee-4211-b59a-d7011bab9ac0@xpipe.io> <4f1b5db5-4e67-414e-9355-ad84535d7e35@xpipe.io> <48790173-8AFF-4F02-BECC-24C41632B64B@gmail.com> Message-ID: > The old code left the BackBufferFormat unspecified and apparently that meant you could get different results on different graphics cards (according to the bug report). Ah, good to know! That would explain why there seems to be no issue on D3D12 - it requires you to specify the format which leaves little room for inconsistencies like that. > The D3D12 branch is very different. I see that the swap chain has the correct format set but the AlphaMode is set to Ignore. When originally writing the SwapChain in D3D12 I opted for ?Ignore? because other modes simply did not work (SwapChain creation was and still is failing when trying to un-ignore AlphaMode). I wasn?t looking much deeper into this, as visually the results matched D3D backend. I did check just now and a simple TRANSPARENT stage seems to work as intended, but that?s probably because we?re redirecting rendering to UploadingPainter as you mentioned. > Doesn?t the UploadingPainter work with hardware acceleration for TRANSPARENT stages on Windows? Correct, in transparent Stages UploadingPainter will be selected even though Pipeline does not declare itself as needing it (so basically all HW pipelines). It also seems to work just fine with hardware acceleration. -Lukasz From: Martin Fox Sent: Thursday, 29 January 2026 22:15 To: Lukasz Kostyra Cc: Christopher Schnick ; OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release The fixes I added for JDK-8154847 were specific to the D3D9 code and would have to be reproduced in D3D12. All I did was ensure that both the swap chain and the device had their BackBufferFormat set to D3DFMT_A8R8G8B8. The old code left the BackBufferFormat unspecified and apparently that meant you could get different results on different graphics cards (according to the bug report). The D3D12 branch is very different. I see that the swap chain has the correct format set but the AlphaMode is set to Ignore. No idea if that?s relevant. Unfortunately I can?t run D3D12 to verify that UNIFIED or translucent backdrops work with D3D12. This makes me nervous because the D3D9 version relies on some magic; in addition to setting the BackBufferFormat there?s a call to DwmExtendFrameIntoClientArea over in glass that allows the swap chain to use its alpha channel. It seems to be triggering the logic in the OS that allowed the old Aero glass effect to work. I just assumed the same would apply to D3D12 but I?m beginning to wonder. On 29/01/2026 12:02, Lukasz Kostyra wrote: That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. For what it's worth: UploadingPainter is normally used with TRANSPARENT stages which are implemented as layered windows. The pixels are passed to GDI using UpdateLayeredWindow which explicitly supports an alpha channel. KickstartFX is using UploadingPainter with a non-layered window and expecting the alpha channel to work. I?m not sure the glass code was designed to ensure that; it seems to be working by accident. The bits are passed to GDI using SetDIBitsToDevice and the documentation says nothing about the alpa channel. I suspect this call is also dependent on the magic DwmExtendFrameIntoClientArea call to make the alpha channel to work. Martin P.S. Doesn?t the UploadingPainter work with hardware acceleration for TRANSPARENT stages on Windows? I thought it drew to a texture and then pulled the bits into RAM and sent them off to the View. On Jan 29, 2026, at 5:37?AM, Lukasz Kostyra > wrote: Indeed it is still there, although on my machine it happens less with Presenting Painter. I tried it a couple of times before sending the email and it worked fine, so seems like I should also go buy a lottery ticket today? Well, good news to me is that this happens on PresentingPainter, so I now have some more possibilities in terms of debugging it in-place. I?ll get back to you when it?s fixed. -Lukasz From: Christopher Schnick > Sent: Thursday, 29 January 2026 13:31 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I commented out the uploading painter line and still see the same issue. As you say, it shouldn't make a difference. Maybe you hit the one time where the issue just didn't occur statistically speaking? The good news is that https://bugs.openjdk.org/browse/JDK-8154847 should be finally fixed by the new translucent backdrop PR, so it shouldn't need this property anymore in the future when it is merged. On 29/01/2026 12:02, Lukasz Kostyra wrote: I looked through KickstartFX and I noticed there?s a point where KickstartFX forces the use of Uploading Painter - PlatformState.java @ 112. UploadingPainter was designed to work with software pipeline as a fallback mechanism (SW does not have the SwapChain/Presentation mechanisms that HW pipelines use) so using it with hardware-accelerated pipelines is not officially supported. When I set prism.forceUploadingPainter to false text and buttons rendered correctly with D3D12 on my machine. Could you check if everything works fine on your end with UploadingPainter disabled? That being said, I do agree there should technically be no visual difference between PresentingPainter and UploadingPainter. I have some theories as to why that would be the case, but because UploadingPainter with hardware pipelines is not officially supported I?ll have to push this issue towards a later point in time. UploadingPainter makes this a bit extra difficult to debug because graphics debuggers rely on applications calling Present() to determine when the application progresses to the next frame - with UploadingPainter no Present() is called and debuggers can?t capture the frame properly for analysis. As for Hyper-V problems - I didn?t get a chance to test these yet but we also did not try running JavaFX with D3D12 backend on virtualized platforms. I will take a look at that use case also at a later point in time, once the performance improvements are completed. For both of these (UploadingPainter issues and Hyper-V issues) I?ll add separate bugs to my backlog and tackle them later down the line. I also checked why UploadingPainter was preferred in KickstartFX and this seems to be the issue -https://bugs.openjdk.org/browse/JDK-8154847. If what Martin mentioned in comment history is correct, there?s a possibility that with D3D12 there should be no transparency issues, as D3D12 defaults to alpha-supported SwapChain buffer (BGRX format exists but presents some technical issues and limitations, BGRA is more convenient). However I had no way of verifying this theory, on my Intel Iris Xe laptop the reproducer works as expected on both D3D and D3D12, with or without UploadingPainter. Let me know if KickstartFX runs properly with PresentingPainter. -Lukasz From: Christopher Schnick Sent: Wednesday, 21 January 2026 13:54 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release Alright, that is good to know. I also ran the d3d12 build in a Hyper-V Windows 11 VM, which are known to cause issues. For example, this issue happens in those VMs with StageStyle.UNIFIED: https://bugs.openjdk.org/browse/JDK-8154847 (kickstartfx uses the unified stage style unless you turn on performance mode in the settings menu) On that system, the app sometimes froze completely, sometimes, the rendered image got stuck. Changing the performance mode setting and the property -Dprism.forceUploadingPainter=true changed the behavior, but it was broken in some way in all configurations. You should be able to reproduce these issues easily with the Windows Sandbox feature: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install On 21/01/2026 13:48, Lukasz Kostyra wrote: Thanks for checking. I ran the KickstartFX build one more time, it failed but I found some leftover global gradle.properties file which defined older JDK which broke the build. Changing JDK to 25.0.1 everything built and works fine. I also found a way to build KickstartFX using custom JFX (customJavaFxLibsPath in build.gradle) and can reproduce your font issues locally on D3D12. I?ll report back when I solve them on my end. :) -Lukasz From: Christopher Schnick Sent: Tuesday, 20 January 2026 16:24 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release In our main application I am getting the following error spammed in the logs: 16:18:08:571 - error: java.lang.NullPointerException: Cannot invoke "com.sun.prism.Texture.getPixelFormat()" because "tex" is null 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:464) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:159) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:123) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGImageView.doRender(NGImageView.java:103) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:571 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2279) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2186) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2213) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.renderNodeToCache(CacheFilter.java:682) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.CacheFilter.render(CacheFilter.java:586) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:2343) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2054) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:266) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2063) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1955) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:481) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) 16:18:08:572 - error: at javafx.graphics at 26-internal/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) 16:18:08:572 - error: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:369) 16:18:08:572 - error: at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) In kickstartfx, I still get the font rendering issues. Can you share the problems you encountered? I tried to build it on a blank VM with git clone, setting a JDK25 in the PATH, and running gradlew.bat run without issues. On 20/01/2026 15:40, Lukasz Kostyra wrote: Hi Christopher, After Christmas break I came back to this issue with some new patches. There were some problems I found with the clear optimization, I just submitted https://github.com/openjdk/jfx-sandbox/commit/8d3ec1deff714caa4eab779581a341e18dd78f31 and according to my local testing everything seems to be fine now. When you have a moment, could you check out the changes above and let me know if everything works correctly in your app? If there are still problems I would like to find a way to build your app and test it locally. I tried doing that earlier via https://github.com/xpipe-io/kickstartfx you linked earlier but encountered some problems when building, so I?m going to need your help or some instructions on how to build the app. Regards, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Wednesday, 10 December 2025 13:29 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release It should work fine without the property. Thanks for your help, I?ll keep searching. -Lukasz From: Christopher Schnick > Sent: Tuesday, 9 December 2025 17:10 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I tried this commit, but the problem shows up again. I tested the previous commit with the passed property again, and that one still works. Or should I still pass the property in this commit as well? On 09/12/2025 4:36 PM, Lukasz Kostyra wrote: Hi Christopher, I updated the direct3d12 branch with the fix - https://github.com/openjdk/jfx-sandbox/commit/ffc078b9593c44a8ed0629a74b8bda18357f93a8 . Let me know how it works and if the problem has been resolved. Thanks, -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Thursday, 4 December 2025 11:52 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release Thanks for checking. I filed https://bugs.openjdk.org/browse/JDK-8373088 to track this since this is unrelated to specifically text, will probably get to it in a few days. -Lukasz From: Christopher Schnick > Sent: Wednesday, 3 December 2025 18:53 To: Lukasz Kostyra > Cc: OpenJFX > Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release This commit fixes the problem when the property is set to false and it shows up again if the property is not set to false On 03/12/2025 5:54 PM, Lukasz Kostyra wrote: Hi Christopher, I did not find the way to reproduce this locally, but I found a problem with one of the optimizations that is in the backend. To double check if that is in fact the issue I pushed https://github.com/openjdk/jfx-sandbox/commit/7078d621dc282ab8439800b84b78377dec3eea89 to disable the optimization (it is on by default, disabling it fixes that specific problem on my end) and I?d like to double-check if this is the correct lead. When you have a moment, could you build JFX with that change and run your app with ?-Dprism.d3d12.clearOpts=false? added to the command line? If the problem persists with prism.d3d12.clearOpts set to false I would need some more information on how these labels are rendered to track this down. Thanks, -Lukasz From: Christopher Schnick Sent: Friday, 28 November 2025 13:25 To: Lukasz Kostyra Cc: OpenJFX Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I did not encounter the vanishing issue anymore with that build, so at least it is usable. However, the font rendering issue still exists for some nodes: It is not deterministic, meaning that if I just scroll the scrollpane forward and back, the same text might get rendered correctly. Also, did you see the performance results I posted for my AMD system? Performance was quite bad there, so this is not in a stage where I can test this in production a bit. On 28/11/2025 12:41, Lukasz Kostyra wrote: Hi Christopher, I just pushed a fix for JDK-8371995 onto direct3d12 branch in the sandbox - https://github.com/openjdk/jfx-sandbox/tree/direct3d12 . If you find a moment, could you build JFX from that branch and check if your app works correctly? -Lukasz From: openjfx-dev On Behalf Of Lukasz Kostyra Sent: Monday, 17 November 2025 15:14 To: Christopher Schnick Cc: OpenJFX Subject: RE: Re: JavaFX Direct3D 12 - Second EA release I might?ve found the problem, there is an assertion that triggers when multiple text objects using different fonts are drawn. It could be related (AFAIK Label controls will eventually end up at the same text rendering routines as Text nodes). Assertions are compiled out on Release for performance, so there is a chance it would corrupt the rendering without anything meaningful shown on screen. To track this I just filed https://bugs.openjdk.org/browse/JDK-8371995. I will check it and let you know when I fix it. On your side It might still be handy to build JFX in DebugNative, to confirm if the triggered assertion is the same and to later confirm if the fix is working for you too. -Lukasz From: Christopher Schnick > Sent: Saturday, 15 November 2025 17:39 To: Lukasz Kostyra > Cc: OpenJFX > Subject: Re: [External] : Re: JavaFX Direct3D 12 - Second EA release Forgot to add, there is nothing out of the ordinary printed in the verbose logs. If I find the time, I can look into compiling a debug build. But the problem should be reproducible somehow when just automatically creating a lot of labels with random styles, sizes, and text. Some of them should break as they did for me. On 15/11/2025 17:34, Christopher Schnick wrote: Ok, so I had more time to debug it. The one weird thing I observed when it was working was that some labels have corrupted text rendering: Not all of them, most are fine. There are no differences in terms of style classes etc. between the labels. When scrolling, the rendering sometimes switches between this corrupted and normal state after some delay. After a while I also figured out that text rendering is responsible for the issue of the nodes vanishing: Certain label contents broke the renderer. For example, in my application, the string "Password manager" when assigned to a label broke it and nothing was rendered anymore. I tried to find an easy reproducer but was not able to. It's probably very dependent on all the different style classes that influence the text shape/size/etc. On 13/11/2025 16:30, Lukasz Kostyra wrote: Thanks for checking. It is very possible the D3D12 runtime did not like something, could be related to your specific hardware. D3D12 by now has many extensions which differ depending on hardware and can lift certain restrictions - we already internally had a case where one GPU had some restriction that was not enforced on another GPU and we had to accommodate that. The first step would be to try running D3D12 with ?-Dprism.verbose=true -Dprism.debug=true?. These should print additional logs that might have some extra information. If there?s nothing useful there, next step would be to build JavaFX with -PCONF=DebugNative - this will compile shaders in Debug, add assertions and debug logs to the backend - and then run your app with D3D12 debug layers and GPU debugging enabled by adding ?-Dprsim.d3d12.debugLayers=true -Dprism.d3d12.gpuDebug=true?. Those will slow down the app significantly, but will also tell D3D12 to run additional API use and GPU use checks. If the problem happens during a render loop and debug layers catch it, there is a chance it will cascade into other errors and spam the console output - you can tell D3D12 debug layers to trigger an assertion on first encountered error with ?-Dprism.d3d12.breakOnError=true?. I am running out of time today to check this myself, but if you find something let me know - I?ll try to reproduce the problem myself and we?ll see where we go from there. Good luck! - Lukasz From: Christopher Schnick Sent: Thursday, 13 November 2025 16:11 To: Lukasz Kostyra Cc: openjfx-dev at openjdk.org Subject: [External] : Re: JavaFX Direct3D 12 - Second EA release I just tried to run a project with provided jmods and at some point, certain nodes are just not rendered anymore and the window contents vanish. But they render for a short period of time. There is no exception thrown as far as I can see, so not sure what you need for debugging. For testing, this is the built application with the d3d12 jmods that you can use to attempt to reproduce the problem: https://we.tl/t-DJuX0BeqXm . It is built from these sources: https://github.com/xpipe-io/kickstartfx On 13/11/2025 14:40, Lukasz Kostyra wrote: Hello openjfx-dev, The second Early Access(EA) build of JavaFX with the Windows Direct3D 12 rendering pipeline is now available at:https://jdk.java.net/javafxdirect3d12/ Please test this bundle and share your feedback by: - emailing openjfx-dev at openjdk.java.net or - reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com This is the second EA release. The backend is feature-complete and went through a first optimization pass, but it still requires some more testing on more hardware variants before we can consider it complete. As such, with this release we also would like to call for help with performance testing the backend (more details on that will be sent in a separate email thread). Known issues and pending tasks are captured on JBS and can be accessed using the filter provided on the Direct3D 12 EA page [https://jdk.java.net/javafxdirect3d12/]. Before reporting a new bug, please review the existing issues to avoid duplicates. Important Notes: 1. This is a Windows-specific feature, so only a Windows-specific bundle is provided. 2. The default rendering pipeline is set to d3d12. Use "-Dprism.order=d3d" or "-Dprism.order=sw" to select one of the other pipelines for comparison testing. 3. It is recommended to use JDK 25 or later. 4. At this stage D3D12 backend is feature-complete and went through the first phase of optimization. It is worth noting that, while generally we noticed performance improvements, it might not be on par with D3D backend on every machine combo - we already noted performance being worse on recent NVidia discrete GPUs [https://bugs.openjdk.org/browse/JDK-8370486] and are looking for solutions. 5. Issue behavior may vary across different hardware, soplease provide detailed information, such as the output of "java -Dprism.verbose=true" or used hardware, when reporting or discussing issues. 6. Refer: Run HelloWorld using JavaFX SDK [https://openjfx.io/openjfx-docs/#install-javafx] We look forward to your feedback. Regards, Lukasz Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Jan 30 14:16:48 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 30 Jan 2026 14:16:48 GMT Subject: RFR: 8154847: Rendering is incorrect or not visible with StageStyle.UNIFIED on some graphics cards In-Reply-To: References: Message-ID: <9U8pCSr288fyxJDKbCf_TWd2Mj8hC4usbCTarel8l_o=.667da284-cfdc-4091-824b-e6c346cd5417@github.com> On Thu, 29 Jan 2026 21:09:16 GMT, Christopher Schnick wrote: > The previous value of BackBufferFormat for the D3DPRESENT_PARAMETERS for the d3d9 swap chain was set to D3DFMT_UNKNOWN by default. This causes the d3d implementation to use a default value, which depends on the system configuration. The RTT texture by JavaFX always uses D3DFMT_A8R8G8B8. > > If the d3d swap chain defaults to D3DFMT_X8R8G8B8, this creates a format mismatch. In theory, that shouldn't be a big deal as it's only about the alpha channel being used or not in this case. But for whatever reason, the format conversion by d3d is completely whack here. This is not only an alpha conversion issue, I tested for that. The whole conversion is wrong. > > This only occurs when using a translucent background, e.g. with the UNIFIED stage style previously. This issue is a blocker for the new translucent backdrops and translucent EXTENDED stage style PRs that are open. Because without this, you can't guarantee that they will display properly on all Windows systems. Most will work fine, but some will be unusable. > > Most d3d swap chain implementations I have seen don't set an explicit BackBufferFormat. However, in the case of JavaFX, it is easier to set the format here than do it for the RTT texture to maintain the same format on all platforms. > > The most important part about this issue is reproduction and testing: I have tested it on multiple Windows 11 systems, Windows 10 1709, and Windows 10 22H2. It fixes the issue on the affected systems and maintains the same behavior on the other systems. > > The reproduction instructions of the original issue are quite old, so it's difficult to get this properly set up on modern systems. The hardware that was affected back then might have gotten driver updates. The easiest way I found was to run Hyper-V on Windows, and create a new MSIX packaging environment VM. > > You can do so at Hyper-V Manager -> Action -> Quick Create -> Windows 10 MSIX packaging environment. This creates a Windows 10 VM which reproduces the issue reliably. The Windows 11 VM does not for some reason. > > You can run the BackdropTest from https://github.com/openjdk/jfx/pull/2048/changes#diff-c25c5ccf435e59b6bfd593251ab6dfc31a12a782a78191a38b4e9adab31587a3 with and without the BackBufferFormat line added to compare. Reviewers: @lukostyra @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/2058#issuecomment-3823989326 From angorya at openjdk.org Fri Jan 30 18:34:29 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jan 2026 18:34:29 GMT Subject: RFR: 8376735: Update Eclipse projects to use JDK25 Message-ID: Updates Eclipse configuration files and the monkey tester readme to jdk25 requirement introduced in [JDK-8370883](https://bugs.openjdk.org/browse/JDK-8370883) Update boot JDK to 25.0.1 [JDK-8376601](https://bugs.openjdk.org/browse/JDK-8376601) Bump minimum JDK version for JavaFX to JDK 25 ------------- Commit messages: - jdk 25 Changes: https://git.openjdk.org/jfx/pull/2059/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=2059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376735 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/2059.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/2059/head:pull/2059 PR: https://git.openjdk.org/jfx/pull/2059 From angorya at openjdk.org Fri Jan 30 18:34:29 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jan 2026 18:34:29 GMT Subject: RFR: 8376735: Update Eclipse projects to use JDK25 In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 17:56:02 GMT, Andy Goryachev wrote: > Updates Eclipse configuration files and the monkey tester readme to jdk25 requirement introduced in > > [JDK-8370883](https://bugs.openjdk.org/browse/JDK-8370883) Update boot JDK to 25.0.1 > [JDK-8376601](https://bugs.openjdk.org/browse/JDK-8376601) Bump minimum JDK version for JavaFX to JDK 25 @hjohn since you are using Eclipse, could you take a look at this please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2059#issuecomment-3825082756 From jhendrikx at openjdk.org Fri Jan 30 21:38:24 2026 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 30 Jan 2026 21:38:24 GMT Subject: RFR: 8376735: Update Eclipse projects to use JDK25 In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 17:56:02 GMT, Andy Goryachev wrote: > Updates Eclipse configuration files and the monkey tester readme to jdk25 requirement introduced in > > [JDK-8370883](https://bugs.openjdk.org/browse/JDK-8370883) Update boot JDK to 25.0.1 > [JDK-8376601](https://bugs.openjdk.org/browse/JDK-8376601) Bump minimum JDK version for JavaFX to JDK 25 This looks good to me; did only the monkey tested need an update? ------------- Marked as reviewed by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2059#pullrequestreview-3730491707 From angorya at openjdk.org Fri Jan 30 21:42:43 2026 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 30 Jan 2026 21:42:43 GMT Subject: RFR: 8376735: Update Eclipse projects to use JDK25 In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 21:36:11 GMT, John Hendrikx wrote: > This looks good to me; did only the monkey tested need an update? The repo contains nested projects - it looks like the top level change resolved all the warnings in the subprojects. The monkey tester has a parallel repository https://github.com/andy-goryachev-oracle/MonkeyTest with its own `build.xml` file, so I just applied the changes from there. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2059#issuecomment-3825894096