"Tools > Options > LibreOffice > Application Colors" dialog's width grows each time when I move the mouse to the right-edge of the dialog, or scrolls the touchpad. Steps to Reproduce: 1. New Calc; 2. Go to "Tools > Options > LibreOffice > Application Colors" dialog. 3. Move your mouse to the right side of the dialog, or use the two-figure scroll on the touchpad. Current Behaviour: dialog's width grows each time when I move the mouse to the right-edge of the dialog, or scrolls the touchpad. Expected: The dialog width stays at it was. It is weird that this only happens for me on Simplified Chinese UI. Reseting user profile does not work. I tested on Tranditional Chinese, English and even KeyID, but do not reproduce on these UIs. Bibisected and bisected to: commit 2f706b1e91396cbe044c20fab79772dfc081a340 Author: Heiko Tietze <tietze.heiko@gmail.com> Date: Fri Aug 27 11:46:57 2021 +0200 Improve accessibility for application color settings Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 2f706b1e91396cbe044c20fab79772dfc081a340 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.3-CN Calc: threaded Fedora 34 x64, Gnome 40.4, Wayland.
Adding Heiko Tietze to cc: would you please take a look? Thanks in advance.
If I change UI and local to Simplified Chinese on Windows builds I can not reproduce on Version: 7.3.0.1 (x64) / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded The Application Colors dialog allows mouse selection of the right edge (cursor change on mouse over), while on a touch screen I am able to select the edge of the dialog and drag it wider or narrower. Functions the same en-US or zh-CN locale.
This may be Linux GTK3 only. Also tested with X11 instead of Wayland, but problem still exists, thus this is not Wayland related.
Does not happen on Fedora 35. Set importance to LOW.
Gtk3 draws the vertical scrollbar over the content for me. Is this causing trouble in your environment? A screencast might help.
Created attachment 177279 [details] screencast
Caolan, any idea what causes this?
never saw that effect but I'd guess the problem is associated with AdjustHeaderBar getting called from the size-alloc handler and calling set_size_request inside that. I don't have a F34 install to make this easy to reproduce, only F35. Though both appear to have gtk3-3.24.30-4
possibly https://gerrit.libreoffice.org/c/core/+/128051 makes a difference if someone who can reproduce this is able to build it
This does not happen for me another PC with Fedora 34 and the same libreoffice version there, but does happen in my previous PC even with fresh profile. So I guess this has sth to do with the Gnome Profile? I am building your patch and testing.
Created attachment 177363 [details] screencast with patchset 3
ok, that's encouraging. One more tweak which helps with the performance of shrinking added to the current effort.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7df337b3636f9df9bf05d7f493e6c89e43c3f5ca tdf#146423 don't set a size-request during a size-alloc It will be available in 7.4.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.
Verified fix on master branch.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0d373003a6a63c3e7e89266668ebc0b42eb2d294 tdf#146423 don't set a size-request during a size-alloc It will be available in 7.3.0.2. 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.