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 stragu
Modified: 2026-04-25 03:14 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, stragu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 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)".
Comment 4 QA Administrators 2026-04-25 03:14:53 UTC
Dear Stéphane Guillou (stragu),

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug