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. >
