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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
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: <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
Message-ID: <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>

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 <credmond at certak.com> 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: <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
Message-ID: <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>

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? <michaelstrau2 at gmail.com> 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 <credmond at certak.com>
> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/6715bae6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_hb.gif
Type: image/gif
Size: 28986 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/6715bae6/bug_hb-0001.gif>

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: <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
Message-ID: <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/b3fb0a95/attachment.htm>

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: <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
Message-ID: <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>

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? <michaelstrau2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/1fa4d2d5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curs.gif
Type: image/gif
Size: 7059 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/1fa4d2d5/curs-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu.gif
Type: image/gif
Size: 31945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/1fa4d2d5/menu-0001.gif>

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: <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
Message-ID: <CAG_-AaC=kC0HaKXES9RfEsPtTa8dg4FCB08UquzTcPdLtA4Htw@mail.gmail.com>

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 <credmond at certak.com> 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? <michaelstrau2 at gmail.com>
> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/a6df82fa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curs.gif
Type: image/gif
Size: 7059 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/a6df82fa/curs-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu.gif
Type: image/gif
Size: 31945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/a6df82fa/menu-0001.gif>

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: <CAG_-AaATEs2q0n=y8hYYNLod_USYqk8tstvA+uO7FLg2oaSuZg@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/caacf8ed/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu_focus.gif
Type: image/gif
Size: 213715 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260101/caacf8ed/menu_focus-0001.gif>

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: <fh2lOQgiepinztNz4eY5JI2XJnrp6dh8pURAvAiPzuA=.c954e1c0-0788-4b4a-9b71-90e73de29bf5@github.com>
References: <fh2lOQgiepinztNz4eY5JI2XJnrp6dh8pURAvAiPzuA=.c954e1c0-0788-4b4a-9b71-90e73de29bf5@github.com>
Message-ID: <hIdcWYjkIDaLGDpR0uhXNj6Tj-hkpJKRYnLInaaTh_s=.36d96412-bb42-4264-8bf6-67212da28f62@github.com>

On Thu, 2 Oct 2025 15:45:33 GMT, Marius Hanl <mhanl at openjdk.org> 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: <CAJEpuXSsb2X2qOCyc+quNpJkntGWht1goDR9hTonG3wnVCK4VA@mail.gmail.com>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
 <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com>
 <D3zcCe6kaK3zg77AmGDgEK3zUKk0GO-SXJ5gfwRM6Mc=.35706501-1b99-43fb-ad5c-82e074ccd3ae@github.com>
 <3312da0d-1d47-45dc-86af-92b59097cd35@xpipe.io>
 <CAJEpuXQd0rKQTfO9Om0g6CUTXP+n6djrv3+xPEq6pPQ_cUnwLg@mail.gmail.com>
 <2f4fc5fb-9d25-4f04-9606-383f260bffaf@xpipe.io>
 <CAJEpuXSsb2X2qOCyc+quNpJkntGWht1goDR9hTonG3wnVCK4VA@mail.gmail.com>
Message-ID: <cedaa7d6-0e58-4978-b590-c8a90b951f31@xpipe.io>

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 <crschnick at xpipe.io> 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: <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
Message-ID: <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>

> 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: <CAG_-AaC=kC0HaKXES9RfEsPtTa8dg4FCB08UquzTcPdLtA4Htw@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
 <CAG_-AaC=kC0HaKXES9RfEsPtTa8dg4FCB08UquzTcPdLtA4Htw@mail.gmail.com>
Message-ID: <CAJEpuXRbLrZ94eD_khRu3+2VjT3Bz-wzOd0Z_u=mkia1-zco1A@mail.gmail.com>

> 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: <CAG_-AaATEs2q0n=y8hYYNLod_USYqk8tstvA+uO7FLg2oaSuZg@mail.gmail.com>
References: <CAG_-AaATEs2q0n=y8hYYNLod_USYqk8tstvA+uO7FLg2oaSuZg@mail.gmail.com>
Message-ID: <CAJEpuXRuSm69V=hqtEH3KkveutTGRL4LfefQM641UK0LWjo8cA@mail.gmail.com>

> 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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <N9xLdy5hgvljECfsH0pvofp_an6avfZ9EGzMvevwG1s=.1c2873da-2d42-433b-a85f-8efcca0f677d@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/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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
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: <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
 <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>
Message-ID: <CAG_-AaDsa5Se-yXX-RPNsjFkwQ7LpCDZtdhoBz+DPuJU7-PK6A@mail.gmail.com>

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? <michaelstrau2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260102/920855e7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_menu.gif
Type: image/gif
Size: 73848 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260102/920855e7/no_menu-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resize.gif
Type: image/gif
Size: 40978 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260102/920855e7/resize-0001.gif>

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: <CAJEpuXRuSm69V=hqtEH3KkveutTGRL4LfefQM641UK0LWjo8cA@mail.gmail.com>
References: <CAG_-AaATEs2q0n=y8hYYNLod_USYqk8tstvA+uO7FLg2oaSuZg@mail.gmail.com>
 <CAJEpuXRuSm69V=hqtEH3KkveutTGRL4LfefQM641UK0LWjo8cA@mail.gmail.com>
Message-ID: <CAG_-AaAKfuc1bSsG_L1SaFE2fShNmd4U-TqkFtH_LB_MDte0Jw@mail.gmail.com>

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? <michaelstrau2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260102/de1c28b8/attachment.htm>

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: <mPos3U76pnLvx2LYEFUWpJBK3NBP6nS3aGBxAkhhbjU=.48e9a00d-dac8-417d-beeb-09f2ed6b1bcb@github.com>
References: <fh2lOQgiepinztNz4eY5JI2XJnrp6dh8pURAvAiPzuA=.c954e1c0-0788-4b4a-9b71-90e73de29bf5@github.com>
 <mPos3U76pnLvx2LYEFUWpJBK3NBP6nS3aGBxAkhhbjU=.48e9a00d-dac8-417d-beeb-09f2ed6b1bcb@github.com>
Message-ID: <qYmjIOIGT9H7dEm2gmXl7YmjB16T33NPaYnX3t7Z3-M=.56942eb0-1098-4686-a3b3-375c5f949e6c@github.com>

On Thu, 6 Nov 2025 12:32:49 GMT, Marius Hanl <mhanl at openjdk.org> 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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <Kxsa0GGmYQrbB5H7a8pH1LAQBlJGp1DRWL-NehDQst0=.7614a1c7-5b8e-49d2-8118-3a4d27e66eb1@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:

  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: <CAG_-AaDsa5Se-yXX-RPNsjFkwQ7LpCDZtdhoBz+DPuJU7-PK6A@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
 <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>
 <CAG_-AaDsa5Se-yXX-RPNsjFkwQ7LpCDZtdhoBz+DPuJU7-PK6A@mail.gmail.com>
Message-ID: <CAJEpuXQf2EbKquzf36UAx6oxijEpB0m-CUtYiNMKiRpHEOQ5uA@mail.gmail.com>

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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <TieElZtvPe0ZdgMJClABjv3aWwHt4PzW-C2xNmTpyAk=.fee8d54e-e251-40eb-a0a9-4f6b1747da1e@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/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: <cedaa7d6-0e58-4978-b590-c8a90b951f31@xpipe.io>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
 <38CostSzOCTV8E68yvXrd9QnvaDh6JAqKrxU5-DUKFQ=.7ce3be34-8d35-4b21-b527-682964949068@github.com>
 <D3zcCe6kaK3zg77AmGDgEK3zUKk0GO-SXJ5gfwRM6Mc=.35706501-1b99-43fb-ad5c-82e074ccd3ae@github.com>
 <3312da0d-1d47-45dc-86af-92b59097cd35@xpipe.io>
 <CAJEpuXQd0rKQTfO9Om0g6CUTXP+n6djrv3+xPEq6pPQ_cUnwLg@mail.gmail.com>
 <2f4fc5fb-9d25-4f04-9606-383f260bffaf@xpipe.io>
 <CAJEpuXSsb2X2qOCyc+quNpJkntGWht1goDR9hTonG3wnVCK4VA@mail.gmail.com>
 <cedaa7d6-0e58-4978-b590-c8a90b951f31@xpipe.io>
Message-ID: <CAJEpuXTLM4p96XJWv-B1Pa3h27pOU=b_EcgJRLQ3Ys2HMSyWmg@mail.gmail.com>

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 <crschnick at xpipe.io> 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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@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:

  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: <Pu64xMTTJGn54-auOYE0a0PjFWcusGeFkbEvv775D2c=.ee399e98-4b99-4a59-8413-b93df0bb7648@github.com>

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: <semKDJlIZqbxSH9SB3C0pT3EyZU0ZBdQC8f3UZripCo=.bc1504f0-79f0-48f2-ba43-ae4337277182@github.com>
References: <semKDJlIZqbxSH9SB3C0pT3EyZU0ZBdQC8f3UZripCo=.bc1504f0-79f0-48f2-ba43-ae4337277182@github.com>
Message-ID: <mkrHOonZ64ABQDqt1Ro4a_LR5JdL7VdEjxguJB9v4Z0=.b7430c40-8a9b-488b-9afa-45a72ad29316@github.com>

On Sun, 4 Jan 2026 16:22:09 GMT, Johan Vos <jvos at openjdk.org> 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 <jvos at openjdk.org>
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: <Pu64xMTTJGn54-auOYE0a0PjFWcusGeFkbEvv775D2c=.ee399e98-4b99-4a59-8413-b93df0bb7648@github.com>
References: <Pu64xMTTJGn54-auOYE0a0PjFWcusGeFkbEvv775D2c=.ee399e98-4b99-4a59-8413-b93df0bb7648@github.com>
Message-ID: <VfSpja7D9SRxBWSLcUkWB7eEpAwGd0lYbjy99XUAnxg=.cd6fdf22-95a1-411c-a144-d666d4b1f23b@github.com>

On Sun, 4 Jan 2026 16:19:06 GMT, Johan Vos <jvos at openjdk.org> 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 <jvos at openjdk.org>
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: <semKDJlIZqbxSH9SB3C0pT3EyZU0ZBdQC8f3UZripCo=.bc1504f0-79f0-48f2-ba43-ae4337277182@github.com>

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: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
Message-ID: <wJtl8lQ0q2gIKIFZoo_dUYJQQty5GEmJYJsc_EErbtE=.230b603c-ff97-43e6-adc5-269379dfec2c@github.com>

On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <VIly_0A7T7aO5-kTx7KLcS5mRwaq7hlN7xVTzggfVPs=.43d3d669-80b4-408f-b630-ff6d6330d50e@github.com>
References: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>
 <VIly_0A7T7aO5-kTx7KLcS5mRwaq7hlN7xVTzggfVPs=.43d3d669-80b4-408f-b630-ff6d6330d50e@github.com>
Message-ID: <9tkldlHZmjDy_6ZSuJbamA2pSjTj9q4nY7hthtkhu5E=.67f774d1-a081-4430-8e05-218d1ed720bc@github.com>

On Tue, 28 Oct 2025 11:33:43 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> This PR fixes `isFocused()` returning invalid value when Stage fails to receive focus after calling `Stage.show()`. This problem is Windows-only.
>> 
>> In Windows the `SetForegroundWindow()` API lists [a set of conditions to successfully grant focus to a Window](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow#remarks). If any of the conditions are not met, the API will return FALSE. JavaFX did not respect that and instead assumed that receiving `WM_ACTIVATE` with our Window being activated is enough to assume the Window is in focus (which in some cases is not true).
>> 
>> I first tried reacting to `WM_SETFOCUS` and `WM_KILLFOCUS` but it seems those messages are not sent when the window is shown for the first time (instead `WM_ACTIVATE` is used).
>> 
>> To correct this behavior, I noticed the following path is the most reliable:
>> - Call `ShowWindow()` using `SW_SHOWNA` instead of `SW_SHOW` - that makes the window visible but does NOT activate it
>> - Call `SetForegroundWindow()` - that will attempt to give the Window focus and will also activate it if it is successful
>>   - If successful, Java `notifyFocus` callback will be called via `WM_ACTIVATE` handler
>>   - If it fails, we call the `notifyFocus` callback manually informing the upper layers the focus is lost. This establishes the correct state of `Window.focused` property.
>> 
>> With this change I observed that all tests pass as intended as long as two conditions are met (these are needed to satisfy `SetForegroundWindow()` restrictions):
>> - Gradle build is ran without the Gradle daemon
>> - The terminal running Gradle test is in foreground
>> 
>> If any of above two conditions is not met, some tests (including canary test from https://github.com/openjdk/jfx/pull/1804) now timeout/fail when checking whether `Window.isFocused()` is true.
>> 
>> Manually started JavaFX apps (ex. Ensemble) run as they used to and still receive focus upon Stage showing.
>
> 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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
Message-ID: <vAl4XR5M0JsEBi-uuNoNmAUXZqR_9T-LZe2_revgVuo=.7c832bc5-3c0a-4739-bc86-75d10f1d6901@github.com>

On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <vAl4XR5M0JsEBi-uuNoNmAUXZqR_9T-LZe2_revgVuo=.7c832bc5-3c0a-4739-bc86-75d10f1d6901@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <vAl4XR5M0JsEBi-uuNoNmAUXZqR_9T-LZe2_revgVuo=.7c832bc5-3c0a-4739-bc86-75d10f1d6901@github.com>
Message-ID: <0ZlHUhsnu9RlWG6a-p2HuEJNcmjqzBSxe4dzRkqRVbk=.5761241a-cd0c-453d-b8a0-7b72da1e0746@github.com>

On Mon, 5 Jan 2026 14:39:46 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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: <CAJEpuXTjD5HYuvH-6eTDPbd0EjNXX0He-+4uSW2ig9UxOgoU9A@mail.gmail.com>
References: <CAJEpuXTDmyo_DEuZp0nH9rc6oVsP1Y2ftiwh8T_QW2WQAQShPg@mail.gmail.com>
 <CAJEpuXTjD5HYuvH-6eTDPbd0EjNXX0He-+4uSW2ig9UxOgoU9A@mail.gmail.com>
Message-ID: <CY8PR10MB7265BC663FA25016BC4F2B7DE586A@CY8PR10MB7265.namprd10.prod.outlook.com>

Michael:

Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245 ?

Thanks,
-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Thursday, December 25, 2025 at 02:49
To: openjfx-dev <openjfx-dev at openjdk.org>
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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260105/1fd688d5/attachment.htm>

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: <CY8PR10MB7265BC663FA25016BC4F2B7DE586A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAJEpuXTDmyo_DEuZp0nH9rc6oVsP1Y2ftiwh8T_QW2WQAQShPg@mail.gmail.com>
 <CAJEpuXTjD5HYuvH-6eTDPbd0EjNXX0He-+4uSW2ig9UxOgoU9A@mail.gmail.com>
 <CY8PR10MB7265BC663FA25016BC4F2B7DE586A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXS=ieCf_=Rc8bun1=+bxoVrpj=Yycehg-7e9btjvOR1Uw@mail.gmail.com>

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 <andy.goryachev at oracle.com> 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: <CAJEpuXS=ieCf_=Rc8bun1=+bxoVrpj=Yycehg-7e9btjvOR1Uw@mail.gmail.com>
References: <CAJEpuXTDmyo_DEuZp0nH9rc6oVsP1Y2ftiwh8T_QW2WQAQShPg@mail.gmail.com>
 <CAJEpuXTjD5HYuvH-6eTDPbd0EjNXX0He-+4uSW2ig9UxOgoU9A@mail.gmail.com>
 <CY8PR10MB7265BC663FA25016BC4F2B7DE586A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXS=ieCf_=Rc8bun1=+bxoVrpj=Yycehg-7e9btjvOR1Uw@mail.gmail.com>
Message-ID: <CY8PR10MB72655B08A15D23185842B55BE586A@CY8PR10MB7265.namprd10.prod.outlook.com>

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? <michaelstrau2 at gmail.com>
Date: Monday, January 5, 2026 at 09:11
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
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 <andy.goryachev at oracle.com> wrote:
>
> Michael:
>
> Does the new approach fix https://bugs.openjdk.org/browse/JDK-8231245  ?
>
> Thanks,
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260105/ef53b132/attachment-0001.htm>

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: <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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: <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
Message-ID: <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com>

On Mon, 5 Jan 2026 16:39:07 GMT, Kevin Rushforth <kcr at openjdk.org> 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>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
 <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com>
Message-ID: <TYj0lD4d5e7ZVS3c2HsJ_9Na9AFL_5wDKfvZtJ22ads=.c6ecc410-add4-4ab7-8b63-27339391f52f@github.com>

On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick <duke at openjdk.org> 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: <jk1IYrkGx6y6SfVYfMxHswEugAEPOUF4aRttdClaWY8=.be21ffb6-2959-4b60-80c3-14e2cbe43807@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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: <qRYg0PUXjyJ_UvUIB6VajGlB_e92n5ktiq3mIu2rcU8=.df175a42-9ac2-4697-aea0-5e757c34fb6e@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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: <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
Message-ID: <rzd_NaZnrDFg9_bVEfcYM5e0k8kBWnKtxmAk5EvN10o=.4e7d3d37-9609-48d5-92ef-52dd997e0308@github.com>

On Mon, 5 Jan 2026 16:39:07 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <rzd_NaZnrDFg9_bVEfcYM5e0k8kBWnKtxmAk5EvN10o=.4e7d3d37-9609-48d5-92ef-52dd997e0308@github.com>
References: <4XxvYuL7xLA0RQMrTLlxOJyhOEWEpudTv-CJZeCe2ek=.657c95f4-fb14-4d15-b351-662519b91d1d@github.com>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
 <rzd_NaZnrDFg9_bVEfcYM5e0k8kBWnKtxmAk5EvN10o=.4e7d3d37-9609-48d5-92ef-52dd997e0308@github.com>
Message-ID: <TiD3MpZzCLa6SM_-P0QBYQHc-BvUbWpGHqMM5g4luuU=.92adb8ff-6777-45d7-994a-9475bf9d52cc@github.com>

On Mon, 5 Jan 2026 17:33:14 GMT, Andy Goryachev <angorya at openjdk.org> 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: <SRkOXnwTVygPbhVASSEBCUBYV1FudBWvriXvphTmwQw=.1932658b-c149-4f90-8efd-900aa9b158da@github.com>
References: <TwJpcdShnf9wsNXXgMttoahj_TFOj8sMfHk78anqNB4=.8ac4ffa1-9ede-439c-973a-a521725b624c@github.com>
 <q8qSh2HthiBGNlkNMeWeFbQDAl7gCreDCIoPJj0iP40=.af1705e7-0b54-45e1-838e-cb6e250a5141@github.com>
 <SRkOXnwTVygPbhVASSEBCUBYV1FudBWvriXvphTmwQw=.1932658b-c149-4f90-8efd-900aa9b158da@github.com>
Message-ID: <QOOv6e41QcXM2QJWPI1M-0WU363vDsBJiAHh1olRBbU=.2d52e7ac-373c-482c-9259-4ecd7c67ae3a@github.com>

On Mon, 29 Dec 2025 19:04:53 GMT, Marius Hanl <mhanl at openjdk.org> 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: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>

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: <ZFVa6y_gYFenWSm3pV0fnkRrHlHk-S8GJTXDhmeZeiw=.0e1b9a92-af32-4442-b824-9544153518a7@github.com>

On Wed, 3 Dec 2025 17:08:24 GMT, Michael Strau? <mstrauss at openjdk.org> 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? <mstrauss at openjdk.org>
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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com>
Message-ID: <hCvSlKD920b5WcdTQhS-MKEbHGToGqcIJoKnJ1K6ZBk=.67078330-ba7c-4ff3-a647-ed082f5d2057@github.com>

On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond <duke at openjdk.org> 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: <puAuGJM8Ztl03Ro4cNprzKrg9zOuWzN6J8snEjZKZK8=.2ef3913a-c8e3-4ccc-b434-7aea5d78f0eb@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <CAJEpuXQFx+BUcVCd-igUbbS+wG-BF57s0H2Lmv279FD7WgiqSg@mail.gmail.com>
 <puAuGJM8Ztl03Ro4cNprzKrg9zOuWzN6J8snEjZKZK8=.2ef3913a-c8e3-4ccc-b434-7aea5d78f0eb@github.com>
Message-ID: <Dinoa9ajKSH1Sn80THUbP1a1tNyaOOBVDSd5tpYqsFQ=.5d8abe1f-64ef-4fb5-ada4-818817a51656@github.com>

On Wed, 15 Oct 2025 17:14:37 GMT, Kevin Rushforth <kcr at openjdk.org> 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
>> \<andy\.goryachev at oracle\.com> 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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com>
Message-ID: <shkaV2pLFLZ2rxGZm-qbDselhOechhBIfCv5SasUGG8=.1d48dc97-057a-40ec-affb-dea7813a1b3e@github.com>

On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond <duke at openjdk.org> 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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
Message-ID: <mZrAV6PZBqz9FKRueBFHbKmECh29GLQUT3tHib3uGcY=.75cbae5f-7f57-4724-b538-55183fc126ae@github.com>

On Sun, 21 Dec 2025 02:42:12 GMT, Cormac Redmond <duke at openjdk.org> 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 <credmond at certak.com>
Committer: Andy Goryachev <angorya at openjdk.org>
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: <CAJEpuXQf2EbKquzf36UAx6oxijEpB0m-CUtYiNMKiRpHEOQ5uA@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
 <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>
 <CAG_-AaDsa5Se-yXX-RPNsjFkwQ7LpCDZtdhoBz+DPuJU7-PK6A@mail.gmail.com>
 <CAJEpuXQf2EbKquzf36UAx6oxijEpB0m-CUtYiNMKiRpHEOQ5uA@mail.gmail.com>
Message-ID: <CAG_-AaD3eF7yz0whcLZ66fdkUKtM8o5Q+OnjJgpc2wQfXwzV8g@mail.gmail.com>

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?, <michaelstrau2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260105/351f9fc0/attachment-0001.htm>

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: <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
Message-ID: <dG4gsfWZgl-SezkYaGh6-0n63s55DO9D9LpyoJGOFN8=.6165a755-e35c-47eb-bb5e-bcca9f45cb68@github.com>

On Mon, 22 Dec 2025 18:08:26 GMT, Andy Goryachev <angorya at openjdk.org> 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: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
Message-ID: <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>

> 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: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
Message-ID: <8nEXguapP8wJyt1gyLm_iJ893fV1j0G61oXuQsNPJF0=.d5b26768-04fa-4a02-bcf8-24d28ed36b61@github.com>

On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
 <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
Message-ID: <oRJO4wqGDrDPmne6DOtVevL81sdK203JMpXlwu4lXt8=.0396448c-9cbf-48ea-b038-83136b84147e@github.com>

On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <oRJO4wqGDrDPmne6DOtVevL81sdK203JMpXlwu4lXt8=.0396448c-9cbf-48ea-b038-83136b84147e@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
 <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
 <oRJO4wqGDrDPmne6DOtVevL81sdK203JMpXlwu4lXt8=.0396448c-9cbf-48ea-b038-83136b84147e@github.com>
Message-ID: <kgwj6qDia9HfsTZ4-uzQsSpHMzbf9Z_bf6q5xTDi9l4=.380c4d9d-75c8-4a24-9152-76f134404f47@github.com>

On Tue, 6 Jan 2026 00:01:06 GMT, Andy Goryachev <angorya at openjdk.org> 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: <puHpt9XNy8AK-zvAf3noxnPgUvynv2HQrcrgWxtTPJg=.5fd679e2-38d4-4a45-9f08-1c2ae93caa9c@github.com>

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: <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
Message-ID: <IjOskkgKOngu8TlW2G-dJCrNKlWex3liwNkN0NxRMy4=.a8e0616c-19f8-4503-ab29-8f41392ef655@github.com>

On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx <jhendrikx at openjdk.org> 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:
>> 
>> <img width="443" height="491" alt="image" src="https://github.com/user-attachments/assets/0342dba3-cd1c-4d9e-9451-e9c8c628b2e2" />
>> 
>> Correct behavior when row 3 is hidden:
>> 
>> <img width="443" height="408" alt="image" src="https://github.com/user-attachments/assets/c7c54414-6a03-43e4-b733-21d0b251d729" />
>> 
>> Behavior before this fix (note the double gap **and** extra grid line):
>> 
>> <img width="443" height="453" alt="image" src="https://github.com/user-attachments/assets/f357e68a-e950-42e7-890b-91a78e194dd0" />
>
> 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: <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
 <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
Message-ID: <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com>

On Mon, 1 Dec 2025 22:36:12 GMT, Andy Goryachev <angorya at openjdk.org> 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: <wH9-xyvA2Kl9JmnRoew42XLuRcp-p1fUhtpUFD45qHM=.31f53403-f564-4432-a4b0-5e6fb6a350db@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <jdlF0j10-7V468ShnrMp2PV4Gi0qzG4oYFx3EF1porI=.6bc0d6e6-2b9f-47dd-9d4a-2f83d7478692@github.com>
 <wH9-xyvA2Kl9JmnRoew42XLuRcp-p1fUhtpUFD45qHM=.31f53403-f564-4432-a4b0-5e6fb6a350db@github.com>
Message-ID: <kNhWgzDhjdmzdWdJAkk3onJ6ObNOvLpzvo_orMOqRKI=.2780b9c6-789f-48e8-9c5b-0be997e24dbe@github.com>

On Tue, 16 Dec 2025 18:24:32 GMT, Andy Goryachev <angorya at openjdk.org> 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: <zErJoDY_NXnHefKdaw2ND0BJLrJbac9esF6z_jzC-CY=.aad43081-acaa-4f1a-a227-0e50aca0cf2b@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
 <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com>
Message-ID: <MUFWN-SeoR05xZI11FFJtnCvSy6t0R4z5gE7jxlZfXI=.4a53bdc9-c9e5-4cd1-b28e-5f80f37e8510@github.com>

On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick <duke at openjdk.org> 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: <miiKaMuiwiVOpCr9F0_JvNfu2rV9c87lo6WLs9sUaDs=.b7c7230d-ac7a-4ca8-8895-6de967e7c289@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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: <ku9roD47bUM9Cxl_5WOe-N6xbQFKT6fxXAL7fx8UPM4=.7bce1709-83f1-434e-9737-55bc569f4c0f@github.com>

On Mon, 5 Jan 2026 10:14:28 GMT, Christopher Schnick <duke at openjdk.org> 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 <cr at crschnick.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
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: <puHpt9XNy8AK-zvAf3noxnPgUvynv2HQrcrgWxtTPJg=.5fd679e2-38d4-4a45-9f08-1c2ae93caa9c@github.com>
References: <puHpt9XNy8AK-zvAf3noxnPgUvynv2HQrcrgWxtTPJg=.5fd679e2-38d4-4a45-9f08-1c2ae93caa9c@github.com>
Message-ID: <C5aQLmsuXIisx2605yaccZv0AksJG1SU8dpxzr_dZ-I=.90ce6d10-b639-4bd4-8bae-652a716774ad@github.com>

On Tue, 6 Jan 2026 07:38:07 GMT, Ambarish Rapte <arapte at openjdk.org> 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>
 <scLWBBNZYTNC5CgxkqonhTKiWzwMYtGvOFV0MtzbcY4=.4d44e958-51c6-4c63-8e40-562c0255c46b@github.com>
 <0yFqTl3ui3xvC7q26gkLowB7zUDa38UHeMjHe0GKdiY=.a2968009-a06e-4371-ac20-30b55a90d360@github.com>
Message-ID: <VucCoIREZnVtlrG2Pu19hcCubkXwFg1DOqBxsnI07-I=.df3e26c8-8ad2-4aed-9c64-46b0475df1f4@github.com>

On Mon, 5 Jan 2026 16:47:14 GMT, Christopher Schnick <duke at openjdk.org> 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: <dG4gsfWZgl-SezkYaGh6-0n63s55DO9D9LpyoJGOFN8=.6165a755-e35c-47eb-bb5e-bcca9f45cb68@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <dG4gsfWZgl-SezkYaGh6-0n63s55DO9D9LpyoJGOFN8=.6165a755-e35c-47eb-bb5e-bcca9f45cb68@github.com>
Message-ID: <vzaFXMnFPPfL-ugfGwYs_gKtd_cehexVHU61zVfEOSw=.1085f76e-c1a8-4499-a4f8-3735166c22b1@github.com>

On Mon, 5 Jan 2026 23:50:45 GMT, Cormac Redmond <duke at openjdk.org> 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: <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
Message-ID: <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>

On Mon, 22 Dec 2025 18:08:26 GMT, Andy Goryachev <angorya at openjdk.org> 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: <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
Message-ID: <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>

On Tue, 6 Jan 2026 14:08:12 GMT, Marius Hanl <mhanl at openjdk.org> 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: <dG4gsfWZgl-SezkYaGh6-0n63s55DO9D9LpyoJGOFN8=.6165a755-e35c-47eb-bb5e-bcca9f45cb68@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <dG4gsfWZgl-SezkYaGh6-0n63s55DO9D9LpyoJGOFN8=.6165a755-e35c-47eb-bb5e-bcca9f45cb68@github.com>
Message-ID: <pjQR7JsB1hfm-2zcOdaxbdpMGyAvjPstpPHzjR607sM=.88c22813-52f9-4fed-878b-80cb534487fc@github.com>

On Mon, 5 Jan 2026 23:50:45 GMT, Cormac Redmond <duke at openjdk.org> 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:

<img width="757" height="324" alt="image" src="https://github.com/user-attachments/assets/f4080156-afbc-4fd0-8d44-d72540398be2" />.

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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <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 <duke at openjdk.org> 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: <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
 <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
Message-ID: <mspwTRu3tbWRkSgATftX2LEWogSV-WiP5j0f3_112Is=.e704e135-e792-45cb-9e00-245dbc26abca@github.com>

On Tue, 6 Jan 2026 14:31:53 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
Message-ID: <Xt-bPQnakRQiaiMPuaP_CMu4lM8cyp6FNY8Jn1yO4qQ=.fc92774f-d2e6-47d2-ab4f-2a62f145a0ea@github.com>

On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
Message-ID: <ZvJoXl81ZGFXmqPuwpeJutBrBmaSvoawDKP3FQrLheU=.9f3b57ec-7e5a-4eef-ab55-bc22c2298609@github.com>

On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
 <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
 <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com>
Message-ID: <jBKMyyOs4gyUkRtAVGtNv7jTULeYvb7yRV1Kx0sC-70=.9a463582-9da0-4c22-8671-731f9071c267@github.com>

On Tue, 6 Jan 2026 07:46:54 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
 <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
Message-ID: <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com>

On Tue, 6 Jan 2026 14:31:53 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <CY8PR10MB7265163A68FC0F102A00BBC5E587A@CY8PR10MB7265.namprd10.prod.outlook.com>

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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260106/8d79561a/attachment.htm>

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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
 <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
 <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com>
Message-ID: <HWnru2GF-sUHqMghLeje7Tk5oMdM0scu-X3Z7-jMLMQ=.985b026b-99c9-40f5-8454-409709dff310@github.com>

On Tue, 6 Jan 2026 15:43:59 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>

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 <https://www.redhat.com>
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: <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
 <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
Message-ID: <obVqLe4ax94mSSd3D5IMLbloOWsyXnQ4S9hxICpJCPM=.6dac3859-f904-42ec-b19a-32f3692c3e1d@github.com>

On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <HWnru2GF-sUHqMghLeje7Tk5oMdM0scu-X3Z7-jMLMQ=.985b026b-99c9-40f5-8454-409709dff310@github.com>
References: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <q5KFxxhFomJWlgukhrdy8ywvTeFcdXYK4iX9LVDNE7M=.0b2155f7-5016-46e8-bdec-eb3d7011a67c@github.com>
 <CnHJc8IpS795aNulhjxE7OEir0d382acn4vliXwBGnQ=.2a239957-7e66-4280-9a4a-0453f80c7b1b@github.com>
 <gCPHqcVP4wsvwRFH-Na0nekIwFm7gUPVKvQJvdk-MbY=.98db2575-5a3e-428e-b29f-2b50ea39587f@github.com>
 <kClm8CIfidmTPn7nrAP4ScwtVOApWeDVj30lRhQiRXo=.55b77928-3e20-470d-970b-dd324d5d89af@github.com>
 <OgSyNvB8zau0qNbh0JPJ-vbW6nSA-pFuEHUPYXib34A=.b9e6ec19-ee82-42ab-a44b-237380d8d8c3@github.com>
 <sIcfYLvxzhfhGCg8-lIdbdw_z6Bh_vDv4Y72qZDZFVE=.db9be95c-7503-4dc9-b0e0-e5754502c409@github.com>
 <9Qs0BJeFQvLd_S4Eq0UfShoj__s8AdiSZgWCROEAs_8=.400396ca-52bd-4f3b-9a78-14dbec92efa7@github.com>
 <HWnru2GF-sUHqMghLeje7Tk5oMdM0scu-X3Z7-jMLMQ=.985b026b-99c9-40f5-8454-409709dff310@github.com>
Message-ID: <vKrdAebEirfLbkhJ7ZnYGc-EyC7p_ju8Z-EHI3h5v2I=.53c8f84f-7a51-4a7a-a644-b1343ff79e12@github.com>

On Tue, 6 Jan 2026 16:12:56 GMT, Andy Goryachev <angorya at openjdk.org> 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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
Message-ID: <ZRbt18rraIBjkbuKvVYgLdl9yXJWYGbcVLKV_5mcQtE=.b910b369-09c1-49ff-9ea5-e8ddf49f21d9@github.com>

> # 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<StyleAttributeMap>' 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: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
Message-ID: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>

> 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: <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
Message-ID: <zbxZucejYxfoOEt6dk-XHJGmlXj8ZdjiRyM6UL4BSJw=.4a0467ac-93b0-4d16-a4da-ae1c1a1333f4@github.com>

On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>
References: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>
Message-ID: <e6dc1000-fa11-42cc-aab9-98bb8976e25d@redhat.com>

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 <https://www.redhat.com>
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: <nIzFxqfsSPSyfnbnC22czQ1-NmzWoLruqYL2GaBA7Mw=.22f397cf-c257-4914-8584-6cca7b0df697@github.com>
References: <mfzOtsvWALk-teirCNaudQZK9ivXPX2fkCy3eAlLvV0=.de2ebf7e-7a77-4c9b-a668-235ff1ee0f54@github.com>
 <nIzFxqfsSPSyfnbnC22czQ1-NmzWoLruqYL2GaBA7Mw=.22f397cf-c257-4914-8584-6cca7b0df697@github.com>
Message-ID: <g9ICZ9dYHQKwJ5vD7O0Oly4NnRvMGONvoHh4NBJ7t2I=.7344c213-8f2e-4d79-9473-3f4dbe01960f@github.com>

On Mon, 22 Dec 2025 23:29:19 GMT, Andy Goryachev <angorya at openjdk.org> 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: <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
Message-ID: <QYtp4csrE0L1KlYvvNV5Lolpjyuvy0ljkNq3_g88UKY=.34be1a0b-dc9f-4720-a1ee-b59dee7772f6@github.com>

On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <ZRbt18rraIBjkbuKvVYgLdl9yXJWYGbcVLKV_5mcQtE=.b910b369-09c1-49ff-9ea5-e8ddf49f21d9@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <ZRbt18rraIBjkbuKvVYgLdl9yXJWYGbcVLKV_5mcQtE=.b910b369-09c1-49ff-9ea5-e8ddf49f21d9@github.com>
Message-ID: <-f5-W7lVg8C9WKwriArrgg9zgZcbBAC5YdxLzIF-Gs4=.0e1cb86d-a849-4ce2-bc27-676dc9d0ce90@github.com>

On Tue, 6 Jan 2026 17:08:33 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <jBKMyyOs4gyUkRtAVGtNv7jTULeYvb7yRV1Kx0sC-70=.9a463582-9da0-4c22-8671-731f9071c267@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
 <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
 <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com>
 <jBKMyyOs4gyUkRtAVGtNv7jTULeYvb7yRV1Kx0sC-70=.9a463582-9da0-4c22-8671-731f9071c267@github.com>
Message-ID: <M2sCpyfnYc7a4vpqS5d3aA6xTPICpRYek6m2HCJzW3Q=.c5327ded-9c76-46fa-ab44-47b273768d31@github.com>

On Tue, 6 Jan 2026 15:29:44 GMT, Andy Goryachev <angorya at openjdk.org> 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: <M2sCpyfnYc7a4vpqS5d3aA6xTPICpRYek6m2HCJzW3Q=.c5327ded-9c76-46fa-ab44-47b273768d31@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
 <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
 <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com>
 <jBKMyyOs4gyUkRtAVGtNv7jTULeYvb7yRV1Kx0sC-70=.9a463582-9da0-4c22-8671-731f9071c267@github.com>
 <M2sCpyfnYc7a4vpqS5d3aA6xTPICpRYek6m2HCJzW3Q=.c5327ded-9c76-46fa-ab44-47b273768d31@github.com>
Message-ID: <f0--kj_0lR_XtVBHAdusKYNeCDGgVuxF3SZ6DLRWi-0=.024d49a8-5b21-46f3-bcf0-a9f86a1ed672@github.com>

On Tue, 6 Jan 2026 20:08:08 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <f0--kj_0lR_XtVBHAdusKYNeCDGgVuxF3SZ6DLRWi-0=.024d49a8-5b21-46f3-bcf0-a9f86a1ed672@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
 <hvHgeoqx8STLRuA_eMjN3nwMZkbl3jm8vjlJHBAOqG4=.b1713a76-3441-4560-af2b-2a55e6db14d5@github.com>
 <eiKtxXiXwfVsvyg_36uwFjU5Byyc2m0bjgBMaNLU16Y=.b1cdeeed-69c6-493b-b772-9a2f4d6d5ff3@github.com>
 <nsPjEpc-jK-Zy4kdi-HiLjDCu_-AfH2UGLRzPpkGyXg=.d858a89c-c204-4dfc-ac78-4d4b904fdcbc@github.com>
 <58_wwG8EuP-zXNLTfMx6LCcSIOG2k9TT8wXJ7T4cegQ=.1c041b6b-95f5-4419-8b22-84569dcc6a8d@github.com>
 <jBKMyyOs4gyUkRtAVGtNv7jTULeYvb7yRV1Kx0sC-70=.9a463582-9da0-4c22-8671-731f9071c267@github.com>
 <M2sCpyfnYc7a4vpqS5d3aA6xTPICpRYek6m2HCJzW3Q=.c5327ded-9c76-46fa-ab44-47b273768d31@github.com>
 <f0--kj_0lR_XtVBHAdusKYNeCDGgVuxF3SZ6DLRWi-0=.024d49a8-5b21-46f3-bcf0-a9f86a1ed672@github.com>
Message-ID: <bi-TeRNFWWbZ8L2rFM85q0-S8Mqm1BzzJvGJUhoj_-Q=.33dffd92-0db4-410d-aeaa-dad7caa1c399@github.com>

On Tue, 6 Jan 2026 20:11:16 GMT, Andy Goryachev <angorya at openjdk.org> 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: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
Message-ID: <4h0v5AQ6exkKXe8BEJiJ5PcFOPVtj23z965kNPhyRZ0=.7e0b798a-44aa-4f4f-9e2a-c1737599ed75@github.com>

On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev <angorya at openjdk.org> 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: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
Message-ID: <AX6-A6OfPRqFJRMJYVIU0mS5FleRgaD6hFhC2wTlY9k=.77b3484c-313a-43c2-89bf-4a0b29070b44@github.com>

On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev <angorya at openjdk.org> 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: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
 <4h0v5AQ6exkKXe8BEJiJ5PcFOPVtj23z965kNPhyRZ0=.7e0b798a-44aa-4f4f-9e2a-c1737599ed75@github.com>
Message-ID: <BjqXfn_j0jASOs9kboYC7S1sDWQVT3OqHiKEgN6ROWo=.6e1c1e0c-53ab-46ea-9ea9-25cbe1006bf5@github.com>

On Tue, 6 Jan 2026 20:25:05 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <CAG_-AaD3eF7yz0whcLZ66fdkUKtM8o5Q+OnjJgpc2wQfXwzV8g@mail.gmail.com>
References: <CAG_-AaCSXihMVr0zMdsOUsGO4anL+WVDct5uwvN8gAj9=qJFQA@mail.gmail.com>
 <CAJEpuXRa0Y4oSDaHw1i-YaZZffv4dxE0CEiG84q8GKtNnK1ZJg@mail.gmail.com>
 <CAG_-AaC8FN40M9LoSwU1+=FgY_5aHj1iMXs2eErkCDnvT3sLdQ@mail.gmail.com>
 <CAJEpuXQZzWpuPTJT9p6b4iR9AcRGv8sd5t6uVU5fygV5yOQ7sg@mail.gmail.com>
 <CAG_-AaAiFmZ6b9Y-W7iXgGVJx5P2NxABPL8TZXBV159mTAsh3g@mail.gmail.com>
 <CAJEpuXQ6SEj0yNXpXH6kHrpzpnykhkc25wrqs0O-P8yocVHqYw@mail.gmail.com>
 <CAG_-AaDFOJag2OLtLPD6Em=a0_52YvqGzTY6xJXTXHXvsUHJuw@mail.gmail.com>
 <CAJEpuXQTi5DcZtX4qoW733of0ir9xTb=gPnZhe0Zk3xX_5Z67Q@mail.gmail.com>
 <CAG_-AaDsa5Se-yXX-RPNsjFkwQ7LpCDZtdhoBz+DPuJU7-PK6A@mail.gmail.com>
 <CAJEpuXQf2EbKquzf36UAx6oxijEpB0m-CUtYiNMKiRpHEOQ5uA@mail.gmail.com>
 <CAG_-AaD3eF7yz0whcLZ66fdkUKtM8o5Q+OnjJgpc2wQfXwzV8g@mail.gmail.com>
Message-ID: <CAG_-AaC+=+_zfvZ5yqkTK2ChURsnGLKenFzLOVGO54yqNB5yqQ@mail.gmail.com>

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 <credmond at certak.com> 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?, <michaelstrau2 at gmail.com> 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: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260106/27b23d5a/attachment-0001.htm>

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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
Message-ID: <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>

> # 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<StyleAttributeMap>' 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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <ZRbt18rraIBjkbuKvVYgLdl9yXJWYGbcVLKV_5mcQtE=.b910b369-09c1-49ff-9ea5-e8ddf49f21d9@github.com>
 <-f5-W7lVg8C9WKwriArrgg9zgZcbBAC5YdxLzIF-Gs4=.0e1cb86d-a849-4ce2-bc27-676dc9d0ce90@github.com>
Message-ID: <H6sfldsWesGT-aGvDNoq78IfXilSMtaXSL_F_Jof9Z8=.96445177-f0fd-4f0e-b7c0-2986b556cc92@github.com>

On Tue, 6 Jan 2026 19:23:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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: <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
Message-ID: <3r_oLrL-wN3yxAGDDjD1kJse9LHBxqpi8XZ2GshFrk8=.60fa5560-676b-4959-bbf7-6f11253fcdf7@github.com>

On Sun, 21 Dec 2025 17:41:44 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <QYtp4csrE0L1KlYvvNV5Lolpjyuvy0ljkNq3_g88UKY=.34be1a0b-dc9f-4720-a1ee-b59dee7772f6@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <s9PGObUjw6JJCQZ9PHw-7BCoomx43CZ6yu2oZ1Y28cg=.e0adfdd0-df7b-4e35-813d-655321c83961@github.com>
 <QYtp4csrE0L1KlYvvNV5Lolpjyuvy0ljkNq3_g88UKY=.34be1a0b-dc9f-4720-a1ee-b59dee7772f6@github.com>
Message-ID: <NeGALFLHSmvvwiwfx5np_XcbrirDodfSUm4U24RlLa4=.08d7f29b-677b-41b4-bbd8-5eef463d7f3a@github.com>

On Tue, 6 Jan 2026 18:45:07 GMT, Martin Fox <mfox at openjdk.org> 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: <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
Message-ID: <DUAvvn2a-KhJ0vRc1Kui6mMxx7eoePicmkWvpHI7eCQ=.e01dc421-94b7-409e-a670-b24d04a0f052@github.com>

On Sun, 4 Jan 2026 01:45:10 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
Message-ID: <MBy73zZYEp_XLrQFjhwy2n05h0yLXr9Z-VbiNyyu1HE=.649425bf-03fa-4fa8-8b42-72daa992f1f4@github.com>

On Sun, 4 Jan 2026 01:45:10 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
Message-ID: <1lvu--OCLcKNYUJErTt5HouiYF9HBS5iMoNYSHT2XLc=.0b1f0487-3585-40e9-b90c-778b1bb09c98@github.com>

On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
Message-ID: <rWlYRvd4Oww8ALYBdUaHmkyGMPS0bwxYkrksM9AuXe8=.3c7efb80-af0e-4aad-a303-dc453ba30718@github.com>

On Sun, 4 Jan 2026 01:45:10 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <HgU3v9OHJcnSPw5Wzlqxc1WWHZY4M25ZkNAb20-bXrI=.8cd3e009-96f1-40e7-a0c6-4d8cae282a7f@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 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: <rWlYRvd4Oww8ALYBdUaHmkyGMPS0bwxYkrksM9AuXe8=.3c7efb80-af0e-4aad-a303-dc453ba30718@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
 <rWlYRvd4Oww8ALYBdUaHmkyGMPS0bwxYkrksM9AuXe8=.3c7efb80-af0e-4aad-a303-dc453ba30718@github.com>
Message-ID: <JAraY8MxxdVl2vmhqR50rfYQvEgytqOZoWYfcA8rXv0=.c631435c-b5d5-4cce-8a80-bf5cf1b980a9@github.com>

On Tue, 6 Jan 2026 21:59:11 GMT, Andy Goryachev <angorya at openjdk.org> 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: <VdqqTYFXBCletYnkMMdY11l6FNOMKBE-Z90lqkbnkAc=.db9e649a-8dbd-479b-8f8b-c8ac646d9997@github.com>
 <2fEiGqpUuyY98vur4-VzFTagLruaMshsrdCbmtxaiYE=.af133f1a-a5c1-4aa8-98ef-a4f7af2d7ec4@github.com>
Message-ID: <txdZMvoqLYeiadnUQujFCe-67WzBF5czCBiEaXQhDG4=.d6ece056-16b7-42a9-b600-565869421d44@github.com>

On Tue, 23 Dec 2025 14:39:21 GMT, Cormac Redmond <duke at openjdk.org> 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: <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
 <eyVHkXjFDvrccFmjICKY4lR5LIuGE8lDVjGPDIHSbw4=.a81aced8-f12c-4cde-b5c8-6b0971e5e919@github.com>
Message-ID: <du9F-haHN-pvCBbowYLss16hfzPe65ePAoLWVtPTSjQ=.d3f21be0-4c4c-4d37-b91e-196960e6ee34@github.com>

On Sat, 29 Nov 2025 20:51:38 GMT, John Hendrikx <jhendrikx at openjdk.org> 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:
>> 
>> <img width="443" height="491" alt="image" src="https://github.com/user-attachments/assets/0342dba3-cd1c-4d9e-9451-e9c8c628b2e2" />
>> 
>> Correct behavior when row 3 is hidden:
>> 
>> <img width="443" height="408" alt="image" src="https://github.com/user-attachments/assets/c7c54414-6a03-43e4-b733-21d0b251d729" />
>> 
>> Behavior before this fix (note the double gap **and** extra grid line):
>> 
>> <img width="443" height="453" alt="image" src="https://github.com/user-attachments/assets/f357e68a-e950-42e7-890b-91a78e194dd0" />
>
> 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: <HgU3v9OHJcnSPw5Wzlqxc1WWHZY4M25ZkNAb20-bXrI=.8cd3e009-96f1-40e7-a0c6-4d8cae282a7f@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <HgU3v9OHJcnSPw5Wzlqxc1WWHZY4M25ZkNAb20-bXrI=.8cd3e009-96f1-40e7-a0c6-4d8cae282a7f@github.com>
Message-ID: <PfdzuR6MILnNkoKQWjINVqYtByilKSGDGWqsQLitvQA=.dc62d1a6-be4b-4cc2-be3e-e226707f0824@github.com>

On Tue, 6 Jan 2026 22:52:34 GMT, Michael Strau? <mstrauss at openjdk.org> 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

<img width="673" height="362" alt="Image" src="https://github.com/user-attachments/assets/ca2ab1f7-47d2-4661-b855-c2ee737d315f" />

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: <MBy73zZYEp_XLrQFjhwy2n05h0yLXr9Z-VbiNyyu1HE=.649425bf-03fa-4fa8-8b42-72daa992f1f4@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
 <MBy73zZYEp_XLrQFjhwy2n05h0yLXr9Z-VbiNyyu1HE=.649425bf-03fa-4fa8-8b42-72daa992f1f4@github.com>
Message-ID: <bUz5SDZMYiCm95SPoqmw7cJP7HK6hBjcY4ILXcsSurU=.fd5b1e85-a653-4f0c-b034-0f45b8902f43@github.com>

On Tue, 6 Jan 2026 21:52:37 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>

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: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>

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: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
References: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
Message-ID: <NwATbIW-uSh8kW7V5vRBFG0aQ-wDLYcFwsr1vFXoUwo=.6432f012-c00e-40e6-831b-e97c9eedacc4@github.com>

On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
Message-ID: <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@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:

  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: <bUz5SDZMYiCm95SPoqmw7cJP7HK6hBjcY4ILXcsSurU=.fd5b1e85-a653-4f0c-b034-0f45b8902f43@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <TPHowNpVE8y2py5Cm6wjFBOhobWR09g-_4TDHiIrsCY=.2578260a-2aa8-4607-86fc-49a1a3c9fcd7@github.com>
 <MBy73zZYEp_XLrQFjhwy2n05h0yLXr9Z-VbiNyyu1HE=.649425bf-03fa-4fa8-8b42-72daa992f1f4@github.com>
 <bUz5SDZMYiCm95SPoqmw7cJP7HK6hBjcY4ILXcsSurU=.fd5b1e85-a653-4f0c-b034-0f45b8902f43@github.com>
Message-ID: <d8jSKZN_VajWYhdXnJ9hWTVFmkhLdvGyAV7u-HLvmuM=.a80e483a-8caf-47ac-9c96-9f4aa0bdb475@github.com>

On Tue, 6 Jan 2026 23:56:03 GMT, Andy Goryachev <angorya at openjdk.org> 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: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
References: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
Message-ID: <IZmz6qGk09qEAT6SQMN0nPaVp7k90-fpqWW6p6vpRtg=.a4a8a449-3557-41d0-add1-6d566c83c467@github.com>

On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
References: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
Message-ID: <ZFiNDEt-CncCpS2u41EGMgwnctr_bLZIRDoEKPpnVJA=.728d4504-5e47-4df4-8925-e46d71510cab@github.com>

On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
 <xiXjvkugwx4ewoVawJqNzs5PCiip1zGcTbwiuYCAL4k=.2714a6da-b70d-4856-ad21-fa85d44a1b1c@github.com>
Message-ID: <hIWYBJ2KVkOVh3HFu0NWefVESgGu6mEc3HEJcZwnmxg=.3a22fbe1-e609-473f-943d-f0b874e83141@github.com>

On Tue, 6 Jan 2026 00:00:51 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
 <zMWs4yhNhaE-A48YGPC84YyJGR4D2MIwn_sx6Ijz9ww=.d3dca1c5-a2e5-4962-afb9-9fc03533cd01@github.com>
Message-ID: <a1mA1wHTQOWn7ZbW7iPv6eaaWwK98yNoFPpYX11gfMU=.85b5c312-bca3-469e-a56c-b827e2c4785b@github.com>

On Mon, 8 Dec 2025 15:11:08 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
References: <vksTpnJ4oih93wQMTxhBh-WmaTiPP_3QmigH0XjGheE=.b3577ce2-12b9-4a90-9447-1d08cfed7f50@github.com>
Message-ID: <yGsxuWUkgDG7exEe1QfyQL46yiShji0YGmTAccHlZGk=.e79c6153-e6fd-4bfb-b13d-8fa78be733b5@github.com>

On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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 <lkostyra at openjdk.org>
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: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
Message-ID: <VRPyrMVi0rECf47jBnuDOohlxNqWFH5XM_-GAT8YiMo=.138055a6-d1fb-44b3-ac9c-78c65b1d749a@github.com>

On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev <angorya at openjdk.org> 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: <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
Message-ID: <JwKM3Dw3DIspN3A2ylf3TRW6WhGcQiU18xgALbl2_js=.3a6da635-39bf-4465-8dd5-dad2fff4b7f6@github.com>

On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>
References: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>
Message-ID: <CAAoP7T4VORuMRW1hwzV7UK39ncUBg5ABQjr4=PGK155DWHck_Q@mail.gmail.com>

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 <fthevene at redhat.com>
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 <https://www.redhat.com>
> BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260107/57bd138a/attachment.htm>

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: <CAAoP7T4VORuMRW1hwzV7UK39ncUBg5ABQjr4=PGK155DWHck_Q@mail.gmail.com>
References: <b737c46d-d78d-4125-b3e8-c4dc674041f3@redhat.com>
 <CAAoP7T4VORuMRW1hwzV7UK39ncUBg5ABQjr4=PGK155DWHck_Q@mail.gmail.com>
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 <fthevene at redhat.com> 
> 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 <https://www.redhat.com>
>     BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
>

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92

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

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: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
References: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
Message-ID: <Q4bFvOjFSQLb2LKztggb_Mmk7aGBZ-gH6WUTgHOD61Q=.322594fc-fcc8-4a27-b321-39ffae89b74e@github.com>

On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <q8qSh2HthiBGNlkNMeWeFbQDAl7gCreDCIoPJj0iP40=.af1705e7-0b54-45e1-838e-cb6e250a5141@github.com>
References: <TwJpcdShnf9wsNXXgMttoahj_TFOj8sMfHk78anqNB4=.8ac4ffa1-9ede-439c-973a-a521725b624c@github.com>
 <q8qSh2HthiBGNlkNMeWeFbQDAl7gCreDCIoPJj0iP40=.af1705e7-0b54-45e1-838e-cb6e250a5141@github.com>
Message-ID: <9oUxymOQCthDVoSH614ifOAwhLkoeVrh0ugegfGSblg=.64b79458-b85c-41ec-b965-cff727068a72@github.com>

On Wed, 24 Dec 2025 17:49:26 GMT, Christopher Schnick <duke at openjdk.org> 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: <hgAb5Tf_8n8oXco1HBD-N18-UP5Z2sztsUtrg0ctfsc=.29eb8ac7-190a-4426-a7e1-a14a1377a333@github.com>
References: <hgAb5Tf_8n8oXco1HBD-N18-UP5Z2sztsUtrg0ctfsc=.29eb8ac7-190a-4426-a7e1-a14a1377a333@github.com>
Message-ID: <q9OFhHbtJ1D8b9P1CRUyhAbnJJhweZta40Yu8I5O4CY=.9487c24d-142d-49dd-96f2-9051c92d175e@github.com>

On Fri, 19 Dec 2025 18:29:43 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
Message-ID: <DdefuP61GXRkdB5aZlVvfb597jSu0mnKrxw8cwcedvA=.13657a77-e016-4be7-bb8c-8e7fc8ac268d@github.com>

On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev <angorya at openjdk.org> 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: <hgAb5Tf_8n8oXco1HBD-N18-UP5Z2sztsUtrg0ctfsc=.29eb8ac7-190a-4426-a7e1-a14a1377a333@github.com>
References: <hgAb5Tf_8n8oXco1HBD-N18-UP5Z2sztsUtrg0ctfsc=.29eb8ac7-190a-4426-a7e1-a14a1377a333@github.com>
Message-ID: <_p2gOZ3U6EZOQJyuhOWALKYbyuwB4sLv4VeD_vtTw1I=.8060acc4-b228-45e6-b19e-3e6d3ced02f7@github.com>

On Fri, 19 Dec 2025 18:29:43 GMT, Kevin Rushforth <kcr at openjdk.org> 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 <kcr at openjdk.org>
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: <puHpt9XNy8AK-zvAf3noxnPgUvynv2HQrcrgWxtTPJg=.5fd679e2-38d4-4a45-9f08-1c2ae93caa9c@github.com>
References: <puHpt9XNy8AK-zvAf3noxnPgUvynv2HQrcrgWxtTPJg=.5fd679e2-38d4-4a45-9f08-1c2ae93caa9c@github.com>
Message-ID: <OaZ07TXWs-wJwnAG7A52hxTvGRFHO6EY-XOJWAXvlt4=.cff17d3f-3fa3-4d21-8ea5-955ec4c444c0@github.com>

On Tue, 6 Jan 2026 07:38:07 GMT, Ambarish Rapte <arapte at openjdk.org> 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 <arapte at openjdk.org>
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: <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
 <CGcaAq7K26McbXEHDV9RHJo1-klQK1mdDlSJO7Jifz4=.9486b798-8bdb-41a2-bef3-6fb41eb28cd4@github.com>
Message-ID: <1eAJWFfiNQmO9FM2DfhE-rUp3ZWiZcHxuYhtK0snO00=.8dd5d301-86db-4209-9475-5d58739046be@github.com>

On Tue, 6 Jan 2026 17:22:51 GMT, Andy Goryachev <angorya at openjdk.org> 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: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
References: <mF_iQa9ETbzSTwsURzd2OTKas_pxZaqiKendaikBRRA=.4c43552d-9427-4535-99bb-faea713852fa@github.com>
Message-ID: <SfKD0dbvcX_SFHTrsB5Ncye5mOww3vbGv7iBhn0xQSY=.32eed3f4-3522-4663-b222-89d5cd2bc5a9@github.com>

On Wed, 24 Dec 2025 22:37:47 GMT, Andy Goryachev <angorya at openjdk.org> 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 <angorya at openjdk.org>
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: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
References: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
Message-ID: <nHzB7nRO3HpTR2IrWqbPeR89hhuR725SrU0sevgrYvU=.574b96ee-f1c0-4420-8b81-f3a198861a55@github.com>

On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
References: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
Message-ID: <NtmypT9JuVJvsfeD2p0MofJxrGzEazzXm8t48P6Sros=.21421b1c-1c31-49a0-9022-6a9de063e961@github.com>

On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth <kcr at openjdk.org> 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):

<img width="1007" height="269" alt="Image" src="https://github.com/user-attachments/assets/e5f69f31-d49d-4968-8658-72b93bdd11ad" />

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

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: <TwJpcdShnf9wsNXXgMttoahj_TFOj8sMfHk78anqNB4=.8ac4ffa1-9ede-439c-973a-a521725b624c@github.com>
References: <TwJpcdShnf9wsNXXgMttoahj_TFOj8sMfHk78anqNB4=.8ac4ffa1-9ede-439c-973a-a521725b624c@github.com>
Message-ID: <cujwHlhurIZwtoKFmkULZd4qAE9N22Z5SrEkZmd8meM=.9b055e72-18ea-4f71-a43e-2d7a475b7d57@github.com>

> 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: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
References: <ClHlFRFnipoBGnVk-oxkIUN99QFb-jl6X1suo0jAbM8=.3fd15394-ecea-429e-9a35-79cb326cb231@github.com>
Message-ID: <rLzkpY96a-zr_ycxS0iG236o9ZlOQwlbzNkki8ZkauM=.8374d370-d880-48af-8dda-ba72f6a7fb8f@github.com>

On Mon, 15 Dec 2025 23:50:34 GMT, Alexander Matveev <almatvee at openjdk.org> 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 <almatvee at openjdk.org>
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: <nHzB7nRO3HpTR2IrWqbPeR89hhuR725SrU0sevgrYvU=.574b96ee-f1c0-4420-8b81-f3a198861a55@github.com>
References: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
 <nHzB7nRO3HpTR2IrWqbPeR89hhuR725SrU0sevgrYvU=.574b96ee-f1c0-4420-8b81-f3a198861a55@github.com>
Message-ID: <CnU95UxT-jJ70FtqSe-R9A0yOMXeEbQHFauf1oQYhWw=.660baf21-d9c0-46d0-bb3f-29e5b437cc43@github.com>

On Wed, 7 Jan 2026 15:29:27 GMT, Andy Goryachev <angorya at openjdk.org> 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: <mYNn70uVuNakKRImlnmzWZzmPnu3CavqSGtDaJjB9D8=.7a89a105-8919-425b-8527-ba54909dde15@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <0S7begIloxySJN5oynf5xlFcp4FmEWczS743LUBtnBM=.3f49cde7-9424-42c7-9fc8-a86c3abb70d2@github.com>
 <mYNn70uVuNakKRImlnmzWZzmPnu3CavqSGtDaJjB9D8=.7a89a105-8919-425b-8527-ba54909dde15@github.com>
Message-ID: <rbi75okTfshOzMd9DUFnJ-2Srt2epWHZjpcgnnux7C4=.e048f9a7-d534-4da4-8856-1564be7f2a40@github.com>

On Mon, 29 Dec 2025 09:10:39 GMT, Pabulaner IV <duke at openjdk.org> 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: <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
Message-ID: <HOjExtCEjmpb8cQslS3iYuxZn1nIxWHZpfwx1rOmwNw=.6f7f0981-4c35-4d55-8c66-7a2f34ac32ca@github.com>

On Wed, 7 Jan 2026 00:19:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
Message-ID: <mWh-LSi0UmK09JH0-e6tjm8d5QiLyLSpH9x4skx7mrM=.b28c66c6-6a6c-420a-a208-c822bac6bbca@github.com>

On Mon, 29 Dec 2025 09:15:28 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

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: <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
Message-ID: <Pdj8ueaSRFy6UOXM06osBeXcRHFMTdt3H9FGUj7qv6w=.1d48b5e8-d295-4648-9978-4ef386952eff@github.com>

On Wed, 7 Jan 2026 00:19:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
Message-ID: <euE31Jz0rjVCkZtgHtgmGmrgjfNCJdcSiy6zHOStAoY=.4b3676d6-8f5a-49ea-90b4-e724590922af@github.com>

On Wed, 7 Jan 2026 00:19:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
Message-ID: <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com>

On Mon, 29 Dec 2025 09:15:28 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

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: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <htgbxOhUsEl5podstKCUEvab0icCiL3AO28D7huzZwk=.77027d28-c52f-4cbb-a7b0-cd0f9aa35629@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
References: <LwnBiVMOfsnBlKPaSv_P99MdGLTYFzV282agrWuXZvM=.45a4b546-241f-4754-99b8-6ed5dee81ab6@github.com>
 <wPAA9aAnrNklGwk5c8pJLmhxYd8nL4-Z8_GCILQ8whc=.53900459-2846-4d41-aea4-20ab809abf9f@github.com>
Message-ID: <rJtNduV8zdlK8ZapQzm1y9zTMuJF9YWBxE54QKzjYZc=.f10f0770-e7f9-44b7-a612-32d8b2f6dbc1@github.com>

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
References: <MhfHl4T6Y4sIZ9wmqhNbD40CMj8jlZQnRA8-RQIv5e0=.bf080556-9e10-4b65-897f-69ec62a903ea@github.com>
Message-ID: <BRd3QsHnsVRUrxod8OmO4kFE4nz0dMV6j7JhDFyYcYE=.8c2d5210-7f28-48e2-be7b-5f35d421c255@github.com>

On Sat, 29 Nov 2025 16:04:51 GMT, John Hendrikx <jhendrikx at openjdk.org> 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:
> 
> <img width="443" height="491" alt="image" src="https://github.com/user-attachments/assets/0342dba3-cd1c-4d9e-9451-e9c8c628b2e2" />
> 
> Correct behavior when row 3 is hidden:
> 
> <img width="443" height="408" alt="image" src="https://github.com/user-attachments/assets/c7c54414-6a03-43e4-b733-21d0b251d729" />
> 
> Behavior before this fix (note the double gap **and** extra grid line):
> 
> <img width="443" height="453" alt="image" src="https://github.com/user-attachments/assets/f357e68a-e950-42e7-890b-91a78e194dd0" />

This pull request has now been integrated.

Changeset: d997dd8b
Author:    John Hendrikx <jhendrikx at openjdk.org>
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: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
Message-ID: <gnrULmFBlbY7-pu5FwKLDaH98ZDm8wGsSxj3xq6TyHA=.5ddc559e-9e67-428d-b9ed-89960d0d16c2@github.com>

> 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: <gnrULmFBlbY7-pu5FwKLDaH98ZDm8wGsSxj3xq6TyHA=.5ddc559e-9e67-428d-b9ed-89960d0d16c2@github.com>
References: <vNWJmCOpMa_CYFnwC1te8zKpMShkdZI1e3LxAp3bDqA=.b57bc0a4-0418-4170-a53e-839f7fa97ede@github.com>
 <gnrULmFBlbY7-pu5FwKLDaH98ZDm8wGsSxj3xq6TyHA=.5ddc559e-9e67-428d-b9ed-89960d0d16c2@github.com>
Message-ID: <gxLEyZkdAF07LS_J1B_zYSE3mon39tfNU9Shuvqrl0M=.9b7cf50e-34e4-44f6-a938-dde2ed50dc3e@github.com>

On Wed, 7 Jan 2026 21:31:11 GMT, John Hendrikx <jhendrikx at openjdk.org> 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: <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
 <zSGBBiGPzAUKAZ4uoL9KOK4mtboeOGNZ0fJYoOCJU1Y=.2a973f6d-03b7-400d-9a7a-14b5c04d5b19@github.com>
Message-ID: <RRb_cB6LL-VgRJmZA4QF6-qV7z0Tz6mX_xejH4Rx9MA=.1bad294c-9e4d-424e-a843-70e1bb3b635b@github.com>

On Tue, 6 Jan 2026 21:07:38 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
References: <XtXPd7hApCh4ZahoPay9SgTihMUDpxQkkRxsNNzxFEQ=.a6a26c3d-44ae-4f6f-a7f1-c3d57330f04b@github.com>
Message-ID: <ghjpAIT4hCqrksO6ahJJX1c0V64eu68Bp1Nf-6GBiQA=.4b3cfa60-fa42-4343-a4ff-8eb8f03a4a35@github.com>

On Tue, 23 Dec 2025 16:51:31 GMT, Andy Goryachev <angorya at openjdk.org> 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<StyleAttributeMap>' 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 <angorya at openjdk.org>
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: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
References: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
Message-ID: <bDBHGXDrnIZLqXfGM9PSEjX6IzcMsTVvGCWWgTqwOng=.514370b3-ac65-46ec-893e-36887a723046@github.com>

On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <rbi75okTfshOzMd9DUFnJ-2Srt2epWHZjpcgnnux7C4=.e048f9a7-d534-4da4-8856-1564be7f2a40@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <0S7begIloxySJN5oynf5xlFcp4FmEWczS743LUBtnBM=.3f49cde7-9424-42c7-9fc8-a86c3abb70d2@github.com>
 <mYNn70uVuNakKRImlnmzWZzmPnu3CavqSGtDaJjB9D8=.7a89a105-8919-425b-8527-ba54909dde15@github.com>
 <rbi75okTfshOzMd9DUFnJ-2Srt2epWHZjpcgnnux7C4=.e048f9a7-d534-4da4-8856-1564be7f2a40@github.com>
Message-ID: <qBaL-jUz4xEqGJyy6sbSF7_JKB0oBroYuSODdsJjxNw=.1d1924d8-e919-4e21-ad5c-61484fc49e06@github.com>

On Wed, 7 Jan 2026 18:07:33 GMT, Kevin Rushforth <kcr at openjdk.org> 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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
 <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com>
Message-ID: <kR8bDnUyCE-4AfGpNkzKZfw_Uq4a4eefBsqdOaifxGs=.0fba42a1-52c1-4c36-bad6-f3c5b246edac@github.com>

On Wed, 7 Jan 2026 19:24:25 GMT, Andy Goryachev <angorya at openjdk.org> 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: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
References: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
Message-ID: <YcoP8c24nqdHDNY8N81MLw0w0OxKvk2cl56DxqTS8pI=.fc3ad290-3111-4c3b-a990-d85bdc993cf6@github.com>

On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
References: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
Message-ID: <dmQqiDXoKZluhsP5cTZs1GMiH5tMRC-IKHSlvk1kes0=.b0f7588c-7107-4cb5-988d-8b3ffe581932@github.com>

On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
References: <xL4c34LUbarnb5RvwxRCyTNEYT7Yqv6q46Gh-FKWdj0=.befc803c-b79a-41c9-a28d-0cf681070731@github.com>
Message-ID: <dkLTqnAvLIgZ0LG8TvU2p34RV1zifF0Dif5u0WZ2Cqw=.9f3ad621-ce70-4307-ac58-c108db352f3e@github.com>

On Wed, 10 Dec 2025 05:34:52 GMT, Michael Strau? <mstrauss at openjdk.org> 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? <mstrauss at openjdk.org>
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: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
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: <Pdj8ueaSRFy6UOXM06osBeXcRHFMTdt3H9FGUj7qv6w=.1d48b5e8-d295-4648-9978-4ef386952eff@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
 <Pdj8ueaSRFy6UOXM06osBeXcRHFMTdt3H9FGUj7qv6w=.1d48b5e8-d295-4648-9978-4ef386952eff@github.com>
Message-ID: <RaZbC8YM2ise9t6Zr-u9Q6MB2aVzb_NZY4E1kIbi66w=.d8c12376-8384-4af6-a6a2-c34b72985326@github.com>

On Wed, 7 Jan 2026 18:49:58 GMT, Andy Goryachev <angorya at openjdk.org> 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: <HOjExtCEjmpb8cQslS3iYuxZn1nIxWHZpfwx1rOmwNw=.6f7f0981-4c35-4d55-8c66-7a2f34ac32ca@github.com>
References: <qDjdUzVADmHdRx1cBEOdySwZKLp25eV4VrX1JgYwFPg=.5eefa9a8-ff8a-473e-9f0d-ab822dda08c0@github.com>
 <tnotqsMVwoXKyNIv1DZQbr514Hm9dxEpg0JbBuVnHH4=.b1c58d54-64f9-4fcf-ac30-879cfb2f9abd@github.com>
 <HOjExtCEjmpb8cQslS3iYuxZn1nIxWHZpfwx1rOmwNw=.6f7f0981-4c35-4d55-8c66-7a2f34ac32ca@github.com>
Message-ID: <b7hwPnjeRHDXlf1d59pGiDS2ZHpWaitEqOiYkMdMqBU=.aa1a4303-c0f2-4f26-9143-76092d4d8d1c@github.com>

On Wed, 7 Jan 2026 17:18:18 GMT, Andy Goryachev <angorya at openjdk.org> 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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
Message-ID: <P6Hn231V7YDsSkvCq_cEzug-SSkSQy8tejm6WjQuDSA=.59fd82e6-bc4e-4ac6-b4da-eb1c53dcb879@github.com>

> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
> 
> # Behavior before
> 
> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
> 
> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
> 
> 
> # Behavior after
> 
> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
> 
> 
> # Tests
> 
> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
> 
> 
> # Additional benifits 
> 
> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
> 
> 
> # Review from AWT
> 
> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
> 
> 
> # Add disable flag?
> 
> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
> 
> 
> Co-Author: @FlorianKirmaier

Pabulaner IV has updated the pull request incrementally with two additional commits since the last revision:

 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX
 - 8359108: Mac - When Swing starts First, native application menu doesn't work for JavaFX

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1904/files
  - new: https://git.openjdk.org/jfx/pull/1904/files/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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <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 <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request 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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
 <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com>
Message-ID: <bZwtLrfTulzO9MFe0kLflBJrl_WY4JCxssywP5KwqdE=.b58610ad-11c8-48fe-bd68-fee463b60866@github.com>

On Wed, 7 Jan 2026 19:28:41 GMT, Andy Goryachev <angorya at openjdk.org> 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: <kR8bDnUyCE-4AfGpNkzKZfw_Uq4a4eefBsqdOaifxGs=.0fba42a1-52c1-4c36-bad6-f3c5b246edac@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <o499S3FoixBEGCv_ieC9TwLf9_lyEzRmbZkishfg4V8=.d270f62a-cd41-48b4-a5fc-165ed8bdfd40@github.com>
 <4ksfPVOku9SrBcJcOWoF_HwkT7OYxp8epvAmumceDLE=.9a86cbad-f9dd-4c9f-9d55-54d36656196c@github.com>
 <kR8bDnUyCE-4AfGpNkzKZfw_Uq4a4eefBsqdOaifxGs=.0fba42a1-52c1-4c36-bad6-f3c5b246edac@github.com>
Message-ID: <s3gscISjV3cmXJvykahI9MDKdR1beGTeerKGDFTTd8Y=.c76c3eac-e302-47ee-a4dd-e0ae9169b4b7@github.com>

On Wed, 7 Jan 2026 22:40:14 GMT, Martin Fox <mfox at openjdk.org> 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: <grVPhLIXwjlLFnGPrMPysGEcuwu90K0skf9xSjPdiGE=.16233034-8d20-4442-aaa2-6687cfed7e5f@github.com>

On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet <fthevenet at openjdk.org> 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 <fthevenet at openjdk.org> 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: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
References: <WC7ixFSWvpWz0vh9sFDmWYdAv80qHRDiUjKunoJjoUw=.2edb2ac7-3dfb-4b6d-b165-b6f271ea0363@github.com>
Message-ID: <tJ7PfLyEbllhWVsItjALOG5MvcE9bpZn_Bvcja1AGBY=.4a56978f-1c3a-4524-aaf8-31f42a658899@github.com>

On Tue, 6 Jan 2026 23:53:14 GMT, Kevin Rushforth <kcr at openjdk.org> 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 <kcr at openjdk.org>
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: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
References: <Lqm_D2_4pw1XBCEkf6BgabA4IGo6pbdoMdlagJ7DOws=.3cf1870b-3188-4654-b5f8-cdaf5ab4aa0d@github.com>
Message-ID: <Gjq48YVRUrixy0iwNqL2q6Hg9gGrNlGOpMeFrI9cMJk=.e720d167-a727-41c0-a191-3611f6236fa2@github.com>

On Wed, 7 Jan 2026 00:13:45 GMT, Kevin Rushforth <kcr at openjdk.org> 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 <kcr at openjdk.org>
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: <grVPhLIXwjlLFnGPrMPysGEcuwu90K0skf9xSjPdiGE=.16233034-8d20-4442-aaa2-6687cfed7e5f@github.com>
References: <1nBNwXwtUKptfiBLOC0EB7Lgw2sJrhAThGLFn4iHN-8=.2ca5ad68-2b6f-40d1-bc93-ec937bc9efed@github.com>
 <grVPhLIXwjlLFnGPrMPysGEcuwu90K0skf9xSjPdiGE=.16233034-8d20-4442-aaa2-6687cfed7e5f@github.com>
Message-ID: <gPQgOmaYRol2snGZPtWtvZGzs0thl62puRgZKb1U8aU=.7444fb94-f3e6-4d55-8469-219ca817f6e9@github.com>

On Thu, 8 Jan 2026 11:24:20 GMT, Lukasz Kostyra <lkostyra at openjdk.org> 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:
<img width="1287" height="1021" alt="GtkFileChooser" src="https://github.com/user-attachments/assets/61e38ec8-64af-4ff7-8e97-9016b4716f2c" />
<img width="1287" height="1021" alt="GtkNativeFileChooser" src="https://github.com/user-attachments/assets/f807420f-4b84-4e6a-b318-9fde3e10bb2f" />

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: <WgLj0iIy8e-fUpJU_O-sxbzN832ltil6Lk3EoiB_JgY=.8bbdc3c5-5e22-49ae-9b3b-b016b7f0ddcf@github.com>

On Tue, 6 Jan 2026 16:02:49 GMT, Frederic Thevenet <fthevenet at openjdk.org> 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: <P6Hn231V7YDsSkvCq_cEzug-SSkSQy8tejm6WjQuDSA=.59fd82e6-bc4e-4ac6-b4da-eb1c53dcb879@github.com>
References: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <P6Hn231V7YDsSkvCq_cEzug-SSkSQy8tejm6WjQuDSA=.59fd82e6-bc4e-4ac6-b4da-eb1c53dcb879@github.com>
Message-ID: <QZ2Da401J5lHv2ZW9ls6CZZcQ_3JhwO4NzF8Oes-GDk=.dadab43f-f0ce-45e3-99d1-9601798a2dfd@github.com>

On Thu, 8 Jan 2026 10:53:58 GMT, Pabulaner IV <duke at openjdk.org> wrote:

>> This pull request fixes the system menu bar on MacOS when combining windows of Swing and JavaFX.
>> 
>> # Behavior before
>> 
>> If for some reason You needed to initialize AWT before JavaFX and You wanted to install the system menu bar from the JavaFX side, this wasn't possible. This issue is persistent even when You didn't open a Swing window. 
>> 
>> One scenario where this kind of issue happens is when You use install4j (see https://www.ej-technologies.com/install4j). In this case AWT is initialized by install4j and therefore You can't use the JavaFX system menu bar anymore.
>> 
>> 
>> # Behavior after
>> 
>> The fix allows JavaFX to install a system menu bar even if it is initialized after AWT. This is achieved by only changing code inside JavaFX. Each JavaFX window stores the previously installed menu bar when gaining focus and will restore this menu bar if the focus was lost. This only happens if the system menu bar installed by the JavaFX window is still unchanged.
>> 
>> 
>> # Tests
>> 
>> This PR introduces tests for the system menu bar in addition to verifying its own behavior / changes. The tests include single- and multi-window tests while interacting with Swing. The tests ensure that the menu bar stays the same for each window, no matter how You switch focus between them.
>> 
>> 
>> # Additional benifits 
>> 
>> This fix is not specifically for AWT, but allows JavaFX to interact much more compatibly with other frameworks that make use of the system menu bar.
>> 
>> 
>> # Review from AWT
>> 
>> In the previous PR related to this one, the comment was made that the folks from AWT should take a look at this fix. It would be great and much appreciated if someone could initiate it.
>> 
>> 
>> # Add disable flag?
>> 
>> We could also add a flag to prevent JavaFX from installing a system menu bar for users who have found other fixes for their projects / setups. This could be used to restore the previous behavior when AWT is initialized first.
>> 
>> 
>> Co-Author: @FlorianKirmaier
>
> Pabulaner IV has updated the pull request incrementally with 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: <FXy1TQ4hGtLF0m3Z7KPBbzXhJ5GGvqGazpJQ8DmOUL0=.6a466dd4-cc09-4378-b8f0-50ec31d86fb8@github.com>
 <2yC2UANGojGiGvUUFeVVMIBmE8rqe00wQm6y9lpPvYM=.3f11215c-ab0a-4f6d-b26e-c04b6fc6fbe6@github.com>
 <-6IlXZ_ghSrj6ip1rfbifjfCkN1LLKma0S6T37nWKRs=.d3ec10fd-9e95-490e-a3d8-982dd3bcddcf@github.com>
Message-ID: <yNWkaQY-9ORoa_XpKuRZy2a5n6-nYUdiqDzdZi3CvBs=.5d2aae16-cf5b-470a-9601-037c6b8638a3@github.com>

On Thu, 8 Jan 2026 10:49:21 GMT, Pabulaner IV <duke at openjdk.org> 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