Created attachment 193688 [details] screenshot of issue Follow-up to bug 152438. Steps: 0. Reduce e.g Writer window size to lower half of display 1. Insert a shape 2. righ-click shape > Format > Area > Area tab > Gradient | Pattern | Hatch 3. Click one of the colour popovers Result: popover expands beyond display Reproduced on Ubuntu 22.04 + GNOME 42.9 + Wayland and: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b599d60fef80039cdfe636a771c3fc8eb1028c3 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded ... as well as 7.3.0.3, but not 7.2.0.4 (in which the popover would pop up, not down). Checked with linux-64-7.3 bibisect repo, started with: commit fae7fd3d193393e4e75ed426b9198925490dc3e4 author Caolán McNamara Fri Nov 19 09:32:55 2021 +0000 committer Caolán McNamara Fri Nov 19 14:57:46 2021 +0100 gtk3: default to an explicit constrain-to for Popovers Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125540
I was unable to replicate this behavior in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded or Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded In both versions, the box opened upwards rather than downwards.
There is no great solution in the sense that under wayland you don't really know the position of the toplevel application window on screen. If you take the position of the menubutton within the dialog as an indicator that those at the top half drop down and those at the top half drop up then this example might look better, but format watermark which is generally small enough to fit the drop down over its parent would then drop up and look weird. Maybe we could consider the size of the dialog, and its position relative to the toplevel application frame and the size of that and then fit the calculated popover size against those to see which side is the best fit
(In reply to Caolán McNamara from comment #2) > There is no great solution in the sense that under wayland you don't really > know the position of the toplevel application window on screen. Seems like this protocol would solve it: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/156 From a comment: "this is just telling the compositor where a representation of a toplevel is located (e.g. button in a panel)".