<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">On my Windows system, I can <i>almost</i> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><img src="cid:ii_mjwwel5g1" alt="resize.gif" width="464" height="193"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">E.g., to the average developer, they're probably not going to understand or think about the resize cursor, or where the top border <i>actually</i> 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).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I imagine, if asked, developers would want a resize cursor to appear 99.9% of the time; <i>even</i> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><img src="cid:ii_mjwvpxl30" alt="no_menu.gif" width="562" height="90"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">So as a default, I feel the resize cursor should be present in some form, always, and it <i>should</i> 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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'm always just considering ease-of-use.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Kind Regards,</div><div class="gmail_default" style="font-family:verdana,sans-serif">Cormac</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 2 Jan 2026 at 12:36, Michael Strauß <<a href="mailto:michaelstrau2@gmail.com">michaelstrau2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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.<br>
<br>
In your example, "left" and "right" are Labels, which don't resize to<br>
fill the available space. There's empty space above the label, and<br>
this empty space is the HeaderBar itself, which is draggable. This is<br>
why you get a resize cursor, the label has nothing to do with it.<br>
<br>
<br>
> 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:<br>
><br>
> 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.<br>
<br>
How do you suggest we solve this? Just forcing a resize border over<br>
potentially interactive elements might work for some applications, but<br>
not for others. Windows File Explorer and Terminal generally have the<br>
same behavior, where you don't get a resize cursor on client content.<br>
However, they do seem to allow for a resize cursor if you manage to<br>
precisely hit the top border of the window (it seems you need<br>
pixel-precise pointing for that). However, tiny resize borders don't<br>
seem to be a good user experience.<br>
<br>
In general, you can of course recreate the IntelliJ behavior by simply<br>
placing a draggable, but visually transparent node across your<br>
MenuBar, aligned with the top of the HeaderBar and its height set to<br>
match the resize border. This will intercept mouse events and give you<br>
a resize cursor.<br>
</blockquote></div></div>