Bug 160673 - Color popovers in Area dialog are cutoff, overflow out of display (GTK, Wayland)
Summary: Color popovers in Area dialog are cutoff, overflow out of display (GTK, Wayland)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.3.0.0 alpha1+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Wayland GTK3 Area-Fill-Tab
  Show dependency treegraph
 
Reported: 2024-04-15 14:41 UTC by Stéphane Guillou (stragu)
Modified: 2024-04-24 16:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of issue (91.61 KB, image/png)
2024-04-15 14:41 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane Guillou (stragu) 2024-04-15 14:41:46 UTC
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
Comment 1 Armondo Lopez 2024-04-15 20:27:47 UTC
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.
Comment 2 Caolán McNamara 2024-04-17 09:24:45 UTC
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
Comment 3 Buovjaga 2024-04-24 16:22:40 UTC
(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)".