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
