Bug 141294 - Decks of Sidebar on HiDPI gets stuck in resize loop upon attempted width adjustment, work around of setting new SB "MinimumWidth" to false in expert config
Summary: Decks of Sidebar on HiDPI gets stuck in resize loop upon attempted width adju...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: All All
: high major
Assignee: Aron Budea
URL:
Whiteboard: target:7.5.0 target:7.4.0.2 target:7.3.6
Keywords: bibisected, bisected, regression
: 144818 145989 146702 147585 148909 149291 (view as bug list)
Depends on:
Blocks: HiDPI Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2021-03-28 01:16 UTC by V Stuart Foote
Modified: 2022-07-24 19:34 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2021-03-28 01:16:38 UTC
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.
Comment 1 Damian Hofmann 2021-04-13 16:57:35 UTC
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
Comment 2 Rick Stockton 2021-10-02 16:36:21 UTC
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).
Comment 3 Rick Stockton 2021-10-02 16:53:24 UTC
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"
Comment 4 V Stuart Foote 2021-10-02 19:23:45 UTC
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
Comment 5 V Stuart Foote 2021-10-19 17:30:07 UTC
*** Bug 144818 has been marked as a duplicate of this bug. ***
Comment 6 Gaetano Giunta 2021-11-08 10:37:23 UTC
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.
Comment 7 V Stuart Foote 2021-12-02 21:42:58 UTC
*** Bug 145989 has been marked as a duplicate of this bug. ***
Comment 8 typingcat 2021-12-02 21:53:23 UTC Comment hidden (me-too)
Comment 9 Damian Hofmann 2021-12-27 17:03:33 UTC
(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
Comment 10 V Stuart Foote 2022-01-25 17:26:11 UTC
*** Bug 146702 has been marked as a duplicate of this bug. ***
Comment 11 V Stuart Foote 2022-01-25 17:55:17 UTC
@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/
Comment 12 V Stuart Foote 2022-02-23 19:08:07 UTC
*** Bug 147585 has been marked as a duplicate of this bug. ***
Comment 13 V Stuart Foote 2022-05-03 22:41:51 UTC
*** Bug 148909 has been marked as a duplicate of this bug. ***
Comment 14 Aron Budea 2022-06-22 04:55:04 UTC
*** Bug 149291 has been marked as a duplicate of this bug. ***
Comment 15 Aron Budea 2022-06-22 09:01:05 UTC
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?
Comment 16 V Stuart Foote 2022-07-19 12:43:12 UTC
*** Bug 147585 has been marked as a duplicate of this bug. ***
Comment 17 Aron Budea 2022-07-20 15:36:19 UTC
https://gerrit.libreoffice.org/c/core/+/137267
Comment 18 Commit Notification 2022-07-21 09:42:46 UTC
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.
Comment 19 Aron Budea 2022-07-21 10:12:07 UTC
Backports are in gerrit.
Comment 20 Commit Notification 2022-07-23 12:10:27 UTC
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.
Comment 21 Commit Notification 2022-07-24 19:34:02 UTC
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.