Menu positioning bug
commit79e1bb53d371c83cf68d8290986c31d2421afa34
authorBrad Jorsch <anomie@users.sourceforge.net>
Fri, 2 Apr 2010 17:31:31 +0000 (2 13:31 -0400)
committerCarlos R. Mafra <crmafra@gmail.com>
Thu, 8 Apr 2010 13:53:50 +0000 (8 15:53 +0200)
treed6c3b13d9c980a691c9b5dcd15d7855f9fba6f82
parentc90484324c8e391f09c582de59e95822c05d610a
Menu positioning bug

I noticed a bug today in menu workspace positioning (in the next tree):
if I right-click and hold the button down at the left edge of the
screen, the menu appears (correctly) half off the edge but will *not*
slide back onto the screen. Compare the behavior to right-clicking at
the right edge of the screen: the menu appears half off the edge, but
sliding the mouse to the edge causes the menu to slide until it is fully
visible.

Also, opening a submenu in this state positions the submenu as if the
menu were fully on the screen, leaving a gap between the menu and the
submenu.

If the menu happens to also go off the bottom of the screen, moving the
mouse to the bottom edge causes the issue to be magically fixed as soon
as the sliding upwards begins.

I also note inconsistent behavior when simply right-clicking (without
holding) to bring up the menu: at the right or bottom edge the menu
appears in the correct partially off the edge position, but at the left
edge it immediately jumps to be fully on-screen, almost as if
WrapMenus = YES were set for the left edge only.

I bisected it to d3162603952a8a00cdafe390791e4e99d2118dc1. As far as I
can tell the "fix" there was to position the menu at the correct
negative X position but then lie to wmaker so it thought the menu was at
X=0. Presumably the "WrapMenus" behavior was the intended result.

Since (AFAIK) the window menu is the only one with this problem, why
don't we just check if x is too negative in OpenWindowMenu()?
src/menu.c
src/winmenu.c