Region PickOnBounds default setting

Pavel Safrata pavel.safrata at
Wed Jun 20 01:12:36 PDT 2012

Hello Daniel,

On 19.6.2012 23:04, Daniel Zwolenski wrote:
> I've always wondered what the behavior when pickOnBounds is false ie. what does it then pick on if not the bounds? Its not intuitive to me from the method name what should happen.

It should pick the node only where the node is physically present. The 
simplest example is a rectangular region with rounded corners. When you 
click just next to the rounded corner, you are inside the (always 
rectangular) bounds, but not inside the region.

> Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look for setMouseTransparent(true) on the region as that's basically what I wanted. Problem was it set all its children transparent too. Perhaps another way out of this problem would be some form of non-inherited mouse transparency attribute. Might be more efficient too.

To achieve the desired behavior, you can set pickOnBounds to false. 
Making the whole region mouse transparent doesn't solve the problem of 
picking it only in the area covered by it. Finally, it still doesn't 
make the platform behave intuitively but introduces another workaround 
that needs to be used manually.

> I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it.

The pane from the description is small and is in a top-left corner. It 
can be styled, and you can see it there. There is no code that would 
make the pane big to cover the whole scene, there is no way to make it 
visible in the whole area, because it's just not there.

> Wouldn't you be just as confused if you were trying to add a pane and it bizarrely wasn't getting mouse events?

I think we should be consistent with other nodes. If you create a node 
that is not filled, it is not picked. If it is filled with a transparent 
color, it is picked. And if you click outside of the node, it is not 
picked - this rule in particular sounds really intuitive to me and 
region doesn't follow it if there is a child or shape somewhere else.

> I'm guessing, for example, if this fix went in it would break all my 'glasspanes'?

I cannot say unless I know how your glasspanes are implemented...

> As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it.

I'm really sad that we've let this go that far, it could have been fixed 
before our first release. If the decision comes that it's too late by 
now, the way how to deal with it will be clear (setPickOnBounds(false)), 
but I doubt it is (and could be) intuitive.


> On 20/06/2012, at 5:41 AM, Richard Bair<richard.bair at>  wrote:
>> Hi folks,
>> We have an issue which has been in the platform from before 2.0:  A better explanation of the issue can be found on From 12258:
>>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples:
>>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place).
>>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child.
>>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region.
>> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true.
>> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think?
>> Richard

More information about the openjfx-dev mailing list