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: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 144818 (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: 2021-11-08 10:38 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


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.