Bug:
Individual Windows can have their titlebar/control created or moved into a _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL restricted zone on the screen.
Details:
While this is not a major problem when the toolbar is on the bottom of the screen, as soon as you move the toolbar to the top of the screen you run into all sorts of situations where a new window can (depending if the app is trying to restore a previous screen location - such as when opened in a different DE) be created with the window title bar underneath the desktop toolbar - rendering the user unable to move that window into the visible area on the screen without knowledge/use of the "alt-<click>" keyboard shortcuts.
Expected Behaviour:
On window creation or move events, Fluxbox should ensure that the window title bar should never enter a _NET_WM_STRUT restricted screen location.
Possible Fix:
It does not appear that Fluxbox is properly updating the _NET_WORKAREA EWMH hint as screen sections get restricted by the _NET_WM_STRUT property. If the _NET_WORKAREA hint is updated properly, it should be a fairly trivial fix to ensure that on window creation/move events the title bar stays within that work area.
Creation: https://sourceforge.net/p/fluxbox/patches/179/
(user-)moving snaps to the strutted area, should imo be sufficient
Configure events are a matter of their own - clients may have reasons to partially move out of screen bounds, otoh. it may be a usabilityproblem if the client is just stupid.
probably fixed now
Status quo: