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 On Wed, 31 Dec 2025 at 01:03, Michael Strauß <[email protected]> wrote: > Hi Cormac, > > The default window buttons are not a part of the scene graph, and no > content in the scene graph can ever occlude them. The only way to get > around this is to hide the default window buttons, and use JavaFX buttons > as a replacement. However, I wouldn't recommend doing that, as blocking > window buttons is almost certainly a very suboptimal user experience. > > The header bar content, on the other hand, is very much part of the scene > graph; this is why you can place a StackPane in front of it and block mouse > events. If you want the header bar to be draggable, you need to allow mouse > events to pass through. This is very much by design: it's what allows you > to place controls in the header bar and interact with them. If the header > bar reacted to mouse events even though a control just consumed them, that > would be very strange and unintuitive. > > Given that HeaderBar is a new feature, it's probably safe to say that > MaskerPane was developed with the understanding that it's okay to cover the > entire client area, and this assumption no longer holds when the client > area is extended to cover the whole window. Maybe MaskerPane can be > improved so that it allows mouse events to pass through if the area under > the cursor is draggable? But that's something for ControlsFX to figure out. > > Michael > > > On Wed, Dec 31, 2025 at 1:22 AM Cormac Redmond <[email protected]> > wrote: > >> Hi, >> >> Sometimes I use a ControlsFx MaskerPane as a "please wait" screen >> whereby I do not want to allow any interactions with any controls >> (including Menus in the HeaderBar if they exist, for example). >> >> I've created a simple dependency-less example to demonstrate something >> similar, and the problem. >> >> When a "masker" is on (StackPane visible), I've noticed that a >> HeaderBar's window icons are still responsive to mouse events, however, *the >> stage cannot be dragged*. This to me suggests different >> handling/priority re: mouse events. >> >> This is unintuitive behaviour to the standard user and it is a very >> noticeable issue for long-lived blocking tasks (for example) where the user >> might need to move a blocked window out of the way. I think if the user can >> resize, restore, minimise, etc., which they can -- then they should also be >> able to drag the window despite a StackPane sitting on top of it. >> HeaderBar.setDragType() doesn't help here. >> >
