Fix border/content-mask sized for a CSD client's whole buffer, margin included

The previous fix for a stale border size (switching effective_frame_of
from dwindow.geometry() to raw dwindow.bbox()) traded one bug for
another. bbox() is the window's entire committed buffer; geometry() is
that buffer intersected with the client's own xdg_surface::
set_window_geometry hint, which excludes any invisible CSD shadow
margin the client reserves around its real visible content. The
assumption behind the switch - that sync_geometry's unconditional
tiled-state bits make every compliant client reserve no such margin,
so nothing would be lost - was wrong: confirmed live via temporary
diagnostic logging, Chrome reserves a real, correctly-current 10px
margin on all four sides regardless of the tiled hint (Firefox, the
window that exposed the original staleness bug, does not - the two
disagree on this).

Raw bbox() therefore handed the border/content mask Chrome's entire
buffer, margin included - 20px wider and taller than its real visible
chrome on each axis, with no compensating position shift - so the
rounded border curve traced a rectangle Chrome's real content never
reached, and its true, still-square corner poked straight through the
curve instead of being hidden by it. Reported live as a border not
lining up with a window's content and a hard block cutting through an
otherwise-rounded corner.

Fixed by keeping both properties at once: dwindow.geometry().loc as
the margin - assumed symmetric (left == right, top == bottom), which
holds for every real CSD shadow margin observed here, since it's a
fixed design constant that doesn't scale with window size and so has
no equivalent staleness window even while the hint's absolute size
does - subtracted from the always-fresh bbox(). Current size, correct
visible-content bounds, for a client that reserves a margin (Chrome)
and one that doesn't (Firefox, whose hint .loc is always (0, 0), where
this reduces to plain bbox()) alike.

0 files changed, 0 insertions, 0 deletions