HeaderBar non-draggable window issue

[Cormac Redmond]

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>