Description: Further to bug 128243 and excessive width of all Sidebar content panel decks (bug 128243) an install of 7.1.1.2 on a MS Surface 4 (screen 2736x1824 at 267 PPI) still suffers from excessive/incorrect X-scale calculation. In a new twist, attemting to adjust width of the Navigator content panel will put LO into a resize loop that can only be cleared by killing the soffice.bin process from TaskManager. Verified it occurs for Skia (Vulkan or Raster) and default GDI rendering. Steps to Reproduce: 1. Clean install of 7.1.1 2. launch Writer 3. Open Sidebar to Navigator deck 4. attempt to drag wider then narrower Actual Results: Enters resize loop. Expected Results: Clean resize (to current limits, but for bug 128243 it should be much narrower). Reproducible: Always User Profile Reset: No Additional Info: Skia not involved. Restarting has no effect, resize loop occurs as soon as attempt to resize the Navigator deck.
Can confirm that I occasionally experience this bug with LO 7.1.0.3. It's not always reproducible for me. Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-CH (de_CH); UI: en-US Calc: threaded
I can confirm this bug to still exist in version 7.2.1 (current release) on Linux, with the system hung and unrecoverable as a result. Version: 7.2.1 Release, build 87b77fad49947c1441b67c559c339af8f3517e22 Hardware: X86-64 Operating System: Linux (OpenSuse Tumbleweed) Desktop Environment: KDE Graphics subsystem: X11 Screen: 4k television HIDPI Version: 7.2.1.2 / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded also: Version: 7.1.5.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded When the "drag" is invoked, the system apparently falls into this loop - and on my Linux Desktop it is absolutely fatal. It is possible to invoke (via Ctl-Alt-Delete) a desktop panel (Power Off / Restart / Logoff) which responds to keyboard entry to activate a choice, but none of those choices work - because the LibreOffice 'Writer' application cannot be terminated in the normal sequence (it is apparently no longer listening for OS signals). Because the mouse location "cursor" is locked as an LibreOffice "drag" (up/down, and side-side are allowed), it cannot open a "terminal window" via clicking (buttons 1-2-3). It probably won't allow entry into in already-shown "terminal" Window either, but I haven't yet tested that. The only recovery on Linux with this Desktop Environnment appears to be the physical "Power Off button. Because it requires an external system crash on Linux, and because my system requires a physical shutdown, I will attempt to raise the Bugzilla "Importance", and mark the problem "New" (confirmed) although I am only a normal user (and unable to become the assignee).
Unable to change priority as a normal user. It requires a system crash on Linux when attempting to logoff and terminate the application, so feel that this bug is "Major"
Dragged out a Surface Pro 4 and installed 7.2.1.2 Issue LO hang on SB deck drag size still occurs, for any Sidebar Deck. No difference with Skia or default GDI rendering--both will hang and lock LO forcing a process kill via WDM task manager. However, setting the expert configuration "Minimum width" (as for bug 140360) boolean "false" prevents the issue from occurring on Windows build. =-testing-= Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
*** Bug 144818 has been marked as a duplicate of this bug. ***
Same problem happening with LO 7.2.2.2 (x64) on Win 10 64 bit 21H1, having 2 monitors attached at different DPI scaling and resolution (I did not test with a single monitor though - it might still happen...). Tested both with Skia rendering enabled and disabled. Trying to close or resize the Navigator side bar sends it in a resizing loop which renders LO unresponsive and can only be stopped by shutting down the process via killing from the operating system.
*** Bug 145989 has been marked as a duplicate of this bug. ***
(In reply to Gaetano Giunta from comment #6) > Same problem happening with LO 7.2.2.2 (x64) on Win 10 64 bit 21H1, having 2 > monitors attached at different DPI scaling and resolution (I did not test > with a single monitor though - it might still happen...). > > Tested both with Skia rendering enabled and disabled. > > Trying to close or resize the Navigator side bar sends it in a resizing loop > which renders LO unresponsive and can only be stopped by shutting down the > process via killing from the operating system. This is 100% reproducible on my computer, and I am using multiple monitors with different DPI. High-DPI problems keep happening with Libre Office even though 4K monitors have been cheap for years. Please, for god's sake, buy some cheap 4K monitors for the developers and testers so that they could find the high-DPI bugs before releasing the software. It is so frustrating that bugs that I often find within minutes after installation keep being included in release versions.
(In reply to V Stuart Foote from comment #4) > However, setting the expert configuration "Minimum width" (as for bug > 140360) boolean "false" prevents the issue from occurring on Windows build. First, thanks for posting this work around. Finally, after struggling for months with this issue, the sidebar is finally usable again (for me). This workaround also helped me discover the "Maximum width" setting. The default value is 500. If I set "Maximum Width" to 1500 and "Minimum Width" to true, the sidebar behaves correctly, as far as I can tell. I can confirm, that the issue still exists in LO 7.2.4.1 if "Minimum width" is set to true AND "Maximum width" set to 500 (default). I have a suspicion, that - on HiDPI screens - LO tends to calculate a "Minimum Width" greater than the default "Maximum Width" of 500 which leads to this infinite resize-loop. --- Display resolution: 3840 x 2160 Scale Factor: 225% Version: 7.2.4.1 (x64) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-CH (de_CH); UI: en-US Calc: threaded
*** Bug 146702 has been marked as a duplicate of this bug. ***
@Samuel, @Szymon given comment 9, is this something additional needed for work handling SidebarController min/max width done for bug 124263? =-ref-= https://gerrit.libreoffice.org/c/core/+/69551/ https://gerrit.libreoffice.org/c/core/+/69561/
*** Bug 147585 has been marked as a duplicate of this bug. ***
*** Bug 148909 has been marked as a duplicate of this bug. ***
*** Bug 149291 has been marked as a duplicate of this bug. ***
Indeed, the immediate problem seems to be that in this call the range is empty (minimum is larger than maximum): https://opengrok.libreoffice.org/xref/core/sfx2/source/sidebar/SidebarController.cxx?r=0ec2b93c#1436 A very simple hack would be to always correct the bounds to a valid range, but that won't make it resizable. Older changes that affected sidebar width on HiDPI screens are as follows, tested on Windows 10 with 4K resolution and 250% scaling. Before the following commit in 6.3, the distance between minimum and maximum was fairly large. Afterwards, the minimum increased a lot, and the sidebar was wide even at the minimum. https://cgit.freedesktop.org/libreoffice/core/commit/?id=a58391b1f61db702a5246c5a33717cbba68c5252 author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2019-03-22 16:17:11 +0100 committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2019-03-25 16:19:13 +0100 "Related tdf#124263 Make sure sidebar is wide enough for content" After the following commit in 7.2, both the minimum/maximum was reduced, and the distance remained small between the two. https://cgit.freedesktop.org/libreoffice/core/commit/?id=84b512ab3d8007293f2e8d338814db3ce7e4a63e author Caolán McNamara <caolanm@redhat.com> 2021-03-30 11:14:12 +0100 committer Caolán McNamara <caolanm@redhat.com> 2021-03-31 21:06:37 +0200 "tabbar is now too wide under windows hidpi" Then the commit that triggers the resize loop for me is the following (in 7.2), but I think only because it increases the calculated minimum width to be larger than the (rather small) maximum. https://cgit.freedesktop.org/libreoffice/core/commit/?id=8fa4371664108560dda438be8fc997d9cfe4bb6e author Heiko Tietze <tietze.heiko@gmail.com> 2021-05-07 12:19:19 +0200 committer Heiko Tietze <heiko.tietze@documentfoundation.org> 2021-05-11 16:10:45 +0200 "Resolves tdf#127406 - Font name and style name not readable" Not sure what would be a consistent minimum/maximum width calculation that equally applies to regular and HiDPI scaling. Caolán, Samuel, do you have thoughts on this?
https://gerrit.libreoffice.org/c/core/+/137267
Aron Budea committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f319363b0e07010eea806c723254f17dacdf1b06 tdf#141294 Use DPI scale factor for sidebar width limit in config It will be available in 7.5.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.
Backports are in gerrit.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/085579ecad6ca7892e9edd0b84e3c28f4a1b8330 tdf#141294 Use DPI scale factor for sidebar width limit in config It will be available in 7.4.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.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/cb2acc2ae1a45e45e5e3dd5907df63aecce0823e tdf#141294 Use DPI scale factor for sidebar width limit in config It will be available in 7.3.6. 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.
*** Bug 140200 has been marked as a duplicate of this bug. ***