BR: Component HitTest area is too small in vertical dimension on macOS [solved - not a JUCE "bug" but Apple "feature"]

I’m not sure how this has gone unnoticed for so long, but components seem to have the hit test area be short by a few pixels on macOS only.

Here is a demo for the issue : GitHub - asimilon/DemoJUCE

You will notice the mouse cursor doesn’t change when approaching from the bottom of the component until it’s a few pixels in, neither will it register a mouse click. For the larger component at the top left this isn’t so much of a problem, but for the very small (10 pixel square) component it’s basically unusuable as almost half of the vertical dimension doesn’t repond to mouse events.

This doesn’t seem to affect Windows, I can’t speak for Linux or other platforms.

I’m not able to reproduce this issue. If I modify the paint() function of the demo to print the mouse coordinates, then for the “small” component, I see a vertical range of 10 logical pixels in which the mouse cursor changes to a pointing hand.

On macOS, the “hot pixel” of the normal cursor is not at the very tip of the white border, but is closer to the point of the black inner arrow. As a result, the white border of the cursor may overlap a hit region without the cursor being reported as “inside” the hit region.

1 Like

Aha, I see now exactly what you mean.

This is somewhat surprising that it’s not the tip of the entire mouse cursor, but just the black part without the white border.

Sometimes macOS does some really stupid things… (I’m looking at you Cmd-Tab to minimised window doing nothing without extra key presses, unlike every other OS)

Not a Mac OS thing. Don’t blame them. Mouse cursors allow the hit point to be specified any place within the cursor image that the designer of the cursor wants it to be. We have several custom cursors, and none of them have the hitpoint in the far upper left pixel. For example, we have a “crosshairs” cursor whose hitpoint is in the middle of the cross. This is pretty common.

Sure, I’m aware of the crosshair for example having the hit point be in the rather obvious place, it’s just my expectation for the “normal” pointer’s hit point would be at the tip of what you see, not some almost arbitrary point displaced 1 pixel to the right and 3 pixels down.

It really does make very small components seem like they are not responding when the pointer image is clearly overlapping but not registering as such. This was my erroneous expectation at the end of the day, but I’m sure I won’t be the last person assuming that what you see would be what you get. WYSINWYG user interface is a new one for me! :joy:

I think I would expect the point that clicks to be the tip of the black inner mouse cursor, this is where there is good contrast, I see the cursor as black with an added white border to help with visibility. When I’ve had small components that need to be clicked in interfaces I’ve sometimes found it useful to make one component that manages the visuals and a second that manages the mouse events, often that second component is bigger than the one representing the visuals. The question to ask yourself is if a user clicked here what were they expecting, and if they are very close to just one component you can bet they probably meant to click that component. You shouldn’t do this just because of a macOS cursor, in my experience it helps to make a UI more user friendly and accessible regardless of the input method used.

My issue with this is that the white border is actually obscuring what you’re trying to click on. How are you supposed to make pixel perfect clicks when you can’t even see the pixel you want to click on? I know this is getting into extreme territory, especially with HiDPI starting to be the norm; trying to click on a pixel your eye can’t even determine as individual is somewhat idiotic, but I come from the days of 320x256 resolutions and pointers who’s hot point was the extreme tip of the pointer as depicted on screen. :person_shrugging:

I’ll go back to yelling at the kids to get off my lawn now… :joy:

1 Like

Totally understand I think it does just require switching away from thinking about individual pixels and ideally, components should be big enough for any user to be able to click them (and a mouse cursor not to obscure them) regardless of the input method (imagine someone with a hand condition that may struggle to be precise, or users with eye trackers, etc).

1 Like