Description: When choosing a color from several Submenus, depending on the position of the window, it's impossible to select the colours of the lower rows. Steps to Reproduce: 1.Draw a rectangle 2.Left click 3.Select "Area" 4.Select "Gradient" Actual Results: It's impossible to choose the colors in the lower rows of the menus "from color" and "to color" Expected Results: The colors in the lower rows of the menus "from color" and "to color" should be available Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: it Module: DrawingDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
I can't reproduce. I put the dialog at the bottom of the screen and the colour selector opened upwards. What is your screen resolution? Was the problem that the colour selector went outside of the screen area? Did you place the dialog at the bottom of the screen? What is your Linux distribution? Please copy and paste here the contents of your Help - About (LibreOffice - About on macOS) by clicking the copy button. This allows us to know more about your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Dear emaildimariorossi, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
(In reply to Buovjaga from comment #1) > I can't reproduce. I put the dialog at the bottom of the screen and the > colour selector opened upwards. > > What is your screen resolution? > > Was the problem that the colour selector went outside of the screen area? > > Did you place the dialog at the bottom of the screen? > > What is your Linux distribution? > > Please copy and paste here the contents of your Help - About (LibreOffice - > About on macOS) by clicking the copy button. This allows us to know more > about your system. > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the information. My screen resolution is 1366*768, i have this issue in both Ubuntu 22.04.3 LTS and Windows 7 version of LibreOffice, here's the copy of the Ubuntu information log: Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: bf0ddd27f701ac1d9e0942bffe145c51e201aa5c CPU threads: 2; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: it-IT (it_IT.UTF-8); UI: it-IT Calc: threaded When in Draw, for example, selecting any colour option, from the column on the right, if this option is placed on the lower part of the column, then the issue shows. I notice it happens only with some submenus. Here's an image to show the problem https://i.postimg.cc/pVDh85W0/Schermata-del-2023-09-08-15-42-12.png
Created attachment 189436 [details] Screenshot of the problem
I can reproduce in 7.3.7.2, 7.6.4.1, and a recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e83c7ec2f4d801365235bf56d7cc8cf31ef4a00e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded This reminded me of bug 153885, which solved it for some popovers. Turns out, for the popover OP uses in their steps, it started at the same commit (at least in my tests; I noticed OP's first affected version does not match...): In linux-64-7.3 repo, first bad build is [faadc0a884c7440df415751320afe5d918a025a3] which points to core commit: commit fae7fd3d193393e4e75ed426b9198925490dc3e4 author Caolán McNamara <caolanm@redhat.com> Fri Nov 19 09:32:55 2021 +0000 committer Caolán McNamara <caolanm@redhat.com> Fri Nov 19 14:57:46 2021 +0100 tree 333516c5e93d2e59ba261b7066a0272f8bcd7231 parent 2337bd5f0d9977a0ecd110abdebea7f331d360df gtk3: default to an explicit constrain-to for Popovers Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125540 Caolán, can you please have a look? Looks like your 11a5ddbb17ddb06c12464f9e961aa9eb42cbf9f9 fix didn't cover all popovers. Works for the split buttons with colour separate from down triangle, but doesn't for the buttons where colour, colour name and down triangle are all together. (Regarding comment 3: we can focus on gtk3 + Wayland here, and see later on in a separate report for Windows if the issue persists.)
Yeah, like last time "This is one of those blasted wayland+gtk things where its very hard to win"
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/601dc3ef9bd74b1948274c104c6c2ec877bc812c Resolves: tdf#152438 constrain popups from MenuButtons with toplevel parent It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán, I tested with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 069bf61cea5e3aea07ffd5a1bb9f55324651cb35 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 OK now with e.g. Sidebar > Properties > Effect > Glow > Color However, still bad for dropdowns in Format > Area > Area tab > Gradient | Pattern | Hatch Would you prefer a follow-up ticket for those?
I think a new bug, but put me on cc. In the popovers inside the main window we seem to be able to get away with this "constraining" the popovers inside the main window and then we can be fairly sure we have enough main window for the popover to fit inside. But for dialogs that isn't always the case, I know there are dialogs smaller than the popover so we can't constrain them inside dialogs in the general case. We have to allow them to escape the surrounding dialog. And in the general wayland case we don't know where the dialog is on the screen to know which direction to position the popover. Assuming I'm guessing right about the remaining problem (include screenshot to be sure because for me the dialog appears in the center of the screen and I have lots of space in which to see the popover) I think the algorithm/hack that I saw used elsewhere was to default popovers to pop downwards if they are in the top half of the dialog, and pop upwards if they are in the bottom half.
(In reply to Caolán McNamara from comment #10) > I think a new bug, but put me on cc. Follow-up in bug 160673. Thanks!