Description: ACTION BUTTONS at the bottom of the DOCUMENT PROPERTIES page in all modules of LO are UNREACHABLE, and PROPERTIES page cannot be resized. This is similar to a bug affecting the PRINT OPTIONS dialog window: FerbTux 2020-04-03 18:20:58 UTC Comment 67 bug id 127782 (#c67) A RELIABLE WORKAROUND IS TO 1- CLICK ON THE PROPERTIES PAGE 2- PRESS ALT-F7 This releases the PROPERTIES page from the Menu bar lock, allowing it to be moved up to expose the ACTION buttons. ~$ libreoffice --version LibreOffice 24.2.0.3 420(Build:3) UNNECESSARY SYSTEM INFO Debian GNU/Linux 12 (bookworm) point version 12.5 kernel 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1 (2024-02-15) GNOME Shell 43.9 display server wayland resolution 1600 x 900 Steps to Reproduce: 1. Open a new document in any LO module 2. In the main menu, select File, Properties 3. Document Properties page is too high for screen and cannot be resized 4. Click on the page, then press Alt-F7 to free the page from the menu bar lock. Actual Results: Workaround is reliable until the UI will be fixed. Expected Results: The WORKAROUND behaves as expected, displaying previously unreachable ACTION buttons. Reproducible: Always User Profile Reset: No Additional Info: A similar bug in LO PRINT OPTIONS page occurred in 2020. SEE: FerbTux 2020-04-03 18:20:58 UTC Comment 67 bug id 127782 (#c67) THE SAME ALT-F7 WORKAROUND WAS USABLE IN THAT CASE UNTIL THE UI WAS FIXED.
Created attachment 193969 [details] screenshot of unresizable Document Properties page Screenshot of LO Document Properties page with unreachable ACTION BUTTONS below the screen edge. The page is locked to the top menu bar, and cannot be resized. However, Alt-F7 unlocks the page, allowing the page to be moved, for access to the ACTION BUTTONS.
Please test in safe mode, Menu/Help/Restart in Safe Mode Please paste here the information on Menu/Help/About LibreOffice (There is an icon to copy) Pls, what is your screen resolution?
Created attachment 193975 [details] Showing that the dialog is resizable Tested on my computer, the dialog is visible and resizable. Also tested i a virtual machine with a resolution of 1599x898, and also is visible an resizable. May be the system and version on LibreOffice is important and necessary. ------------------ Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded
Additional unsuccessful attempts to fix oversized (and not resizable) Document Properties window page: * Turned OFF Attach Modal Dialogs (to parent window) in DConf Editor at org.gnome * Tried all installed LO icon themes (LO Options, View, Icon Theme) * Changed Options, View, Icon Size for Toolbar, Notebook, Sidebar to SMALL * Reverted all menu configurations to Default (which was my initial setting anyway.) ~$ sudo apt list -a libreoffice Listing... Done libreoffice/stable-backports,now 4:24.2.0-1~bpo12+1 amd64 [installed] libreoffice/stable,stable-security 4:7.4.7-1+deb12u1 amd64 @jcsanz: I believe you're right, the system and version matters. I think this issue involves GTK4 (hence, not Windows builds.) I have the latest .deb available in bookworm-backports (which is not the very latest release,) and will look forward to the hoped-for fix in a future backports update. Thank you for attempting to confirm this bug. Correction! I speculated that the oversized LO Document Properties window was a GTK+4 issue. However, I just now checked, and I have GTK+ 3, 4, and 5 installed. Moreover I also have qt5 with Wayland support. This may more complicated than I imagined.
I assume this is since the fix for bug 138792, adding various fields in the Description tab. Indeed, at a resolution 1600×900 like yours (which is above the minimum resolution supported[1]), the dialog does fit (as in comment 3) with win, gen, kf5 and qt5 VCL plugins, but I also tested on Ubuntu 22.04 + GNOME 42.9 and can confirm that the buttons overflow at the bottom. Sarper, Heiko, what do you think? [1]: https://www.libreoffice.org/get-help/system-requirements/
Either the (less relevant) attributes are put into a dropdown. Or we add a GtkScrolledWindow behind the large number of controls. And a quick and dirty solution could be to reduce the Comments-height. Since this affects all users we should fix it until the upcoming release.
~$ libreoffice --version LibreOffice 24.2.3.2 420(Build:2) ~$ lsb_release 2>/dev/null -ds; printf "point version "; cat /etc/*_version; printf "kernel "; uname -r; gnome-shell --version; printf "display server "; echo $XDG_SESSION_TYPE # DESCRIBE SYSTEM SESSION Debian GNU/Linux 12 (bookworm) point version 12.5 kernel 6.7.12+bpo-amd64 GNOME Shell 43.9 display server wayland The RESIZE arrows do appear in my case (above,) but do not allow resize-smaller. The window can be enlarged top-left-right, but cannot be resized smaller. The top border of the window cannot be moved above the document window border.
I can reproduce this with LO 24.2 on Linux with a 2x scaling: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Other than this one, "Options" dialog and many other dialogs has the exact same problem on my screen which uses 2x scaling. Part of the window goes out of the screen. I expect more of these bugs with 2x, 3x scaling, etc. which are more common these days. Maybe we should find a solution that can handle oversized dialogs. There are mechanisms for oversized menubar, like scrolling. Then, why not having something similar for oversized dialogs? Possible options are scrolling, resizing, scaling, and things like that. This can be a fallback, when even with the careful design and implementation, some dialog does not fit on the screen.
@Heiko: I filed another ticket, tdf#161240 which describes what I am saying here in more details. It is more general, beyond this specific case.
(In reply to Hossein from comment #8) > I can reproduce this with LO 24.2 on Linux with a 2x scaling: 2× scaling, but what resolution? Higher scaling factors are more common because higher resolutions are more common. My understanding is that our minimum resolution system requirement of 1024×768 is at 100% scaling, and if a scaling factor is applied, the same should be applied to the resolution values. So if someone uses 2× scaling, we expect them to use a minimum resolution of 2048×1536.
(In reply to Stéphane Guillou (stragu) from comment #5) > I assume this is since the fix for bug 138792, adding various fields in the > Description tab. > > Sarper, Heiko, what do you think? > Yep this is since the fix for bug 138792 indeed. All solutions suggested by Heiko on comment #6 makes sense to me.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2164406a973fd40fcc56b8839a21854f6b50a53b Resolves tdf#160937 - Improve dialog size for document properties 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.
OMG! Was this the change, when you created a drop-down, which gives that AWFUL idea (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! YES I SCREAM, I already pleaded to NEVER EVER implement this broken, weird, sinister UI, and drop it from Options->Load/Save->General - it is just ignored), that user selects something in the drop-down, then sets *respective* value in another control? I already provided Ask questions showing user confusion for the Options->Load/Save->General. Now there is tdf#162738, showing the same confusion in the newly changed Description tab. No, this is never a good option. We need to create an automatic reject policy for this UI anti-pattern. UX should finally realize this simple idea. Please.
Bug 88589 is a sample right here in the Bugzilla. Bug 148756 comment 7 starts the discussion, and Bug 148756 comment 10 provides references showing confusing people. The next comment was Heiko's "Okay, good argument", dated 2023-05-08, which didn't prevent this change from one year later, 2024-05-29.
(In reply to Mike Kaganski from comment #13) > AWFUL idea... Alternatives are splitting the input into different views (new tab, tab in tab, extra dialog etc.), a scrolled view, and/or an expander for the new options. Wouldn't call the dropdown/list selection an anti-pattern per se.
(In reply to Heiko Tietze from comment #15) > Wouldn't call the dropdown/list selection an anti-pattern per se. Me either. But having two controls in a "form" / dialog, like what you created - a drop-down list plus a connected edit box, connected in a completely unintuitive, unfamiliar way, when selecting anything in the "master" drop-down (1) stores the value of the dependent control to the internal memory; (2) fills the dependent control with the value corresponding to the new "master" drop-down value - so that these two controls work like several separate edit controls earlier - but the user doesn't see that, and naturally sees that "you only select one type of the value, and fill it, and can't fill the data to all of the types" - definitely IS the anti-pattern. And I already described that to you on IRC. Now let me record it right here.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3631c6ffcb2f27090cfc1b1c9dd492451d3d485c Resolves tdf#162738 - Revert tdf#160937 It will be available in 25.2.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.
Now with a scrolled view behind the description items, https://gerrit.libreoffice.org/c/core/+/172881
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5c64b81b4d5bd347e57ba156bb0c34d09fb6aa5b Resolves tdf#160937 - Minimize document properties dialog size It will be available in 25.2.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.
The game is famous for its simple yet challenging gameplay, and its quick success has made https://flappybirdgame.io a global phenomenon.
Confirming that the document properties sheet issue has been resolved in LibreOffice 24.8.2.1 480(Build:1) ! ! ! This update was received Thu 2024 Oct 03: Debian GNU/Linux 12 (bookworm) point version 12.7 kernel 6.10.6+bpo-amd64 GNOME Shell 43.9 display server wayland I am using bookworm-backports. Thank you all for your efforts!