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ß <[email protected]> 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 <[email protected]>
> 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
>
