This only happens when LibreOffice is using the KDE5 or Qt5 plug-in. Steps to produce: Create new document. Modify a paragraph style. Select the Outline & List tab. Select a List style. Click on Edit Style. Pretend that you accidentally clicked on a button in the parent Paragraph Style window instead of a button in the Outline & List window. LibreOffice now goes into a loop that can only be exited by clicking really fast on a button in the Outline & List window or by killing the process from another terminal. Sometimes the loop will happen by clicking on day Edit Style button without clicking on another window first. I'm using the current Debian Stable with KDE Plasma.
The previous comment should read: Pretend that you accidentally clicked on a button in the parent Paragraph Style window instead of a button in the List Style window. LibreOffice now goes into a loop that can only be exited by clicking really fast on a button in the List Style window or by killing the process from another terminal. Sometimes the loop will happen by clicking on an Edit Style button without clicking on another window first.
What version of LibreOffice? Go to Help - About
7.x, 6.x, 7.3 alpha. Appimages earlier than 6.x work, but the issue may have only began though after upgrading to latest Debian Stable.
Yet an other Qt modal handling problem; how I love them :-( Really time to re-visit the parent handling code and fix it to build a real QWidget hierarchy, which doesn't crash LO at some point ... somehow. This deadlocks the whole Plasma session for me. Kudos for finding the workaround "... that can only be exited by clicking really fast on a button in the List Style window or by killing the process from another terminal." FWIW LO is idle at this point. AFAIK it's really Qt modal handling breaking with LO's non-hierachy of Qt widgets.
So Qt doesn't like two modal dialogs with the same parent. IMHO that generally does make sense. LO-internally, the "paragraph style" and the "list style" edit dialogs are modal and parented on the Writer window. That probably also explains, why I can switch between both dialogs in gtk3 and gen (x11), but just change the "list style" one with the STR. At least both don't totally break like Qt. Eventually the correct fix would be to somehow tell the dispatcher to select the correct parent for the modal dialog. Maybe LO should auto-reparent modal dialogs. There is now https://gerrit.libreoffice.org/c/core/+/124500. This re-parents new modal dialogs on top of the Qt modal stack. I'm not sure this is the wanted behavior, but I don't think anything else wrt to modal dialogs is implementable with Qt.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e4abf879f4a24258bcc560eb58ca78b147768d46 tdf#145363 Qt popups actually are windows It will be available in 7.3.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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b00a68a8e19370e106cd76258a3c1825f43613ee tdf#145363 Qt reparent modal dialogs on show It will be available in 7.3.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.
Created attachment 176060 [details] test document I think this may have gotten closed a little prematurely. The looping issue indeed does seem to be fixed, but the fix seems to have introduced a new problem, although I guess it could be a coincidence. If it is a coincidence and the issue just happened to be caused by another recent fix, I'll mark this bug fixed again and open a new bug report. If a style is extensively modified, then the settings line underneath the Contains section in the Organizer tab does not wrap. The width of the dialog box instead expands to fit the line and may go off the screen. I attached a file to demonstrate the problem. You can modify the Default Paragraph Style to see the issue.
The text in the Help | About LibreOffice window is also not wrapping.
For me this also happens with SAL_USE_VCLPLUGIN=gen, but not with SAL_USE_VCLPLUGIN=gtk3. AFAIK it's likely weld related and all platforms except gtk3 are now broken. But my build is a few days old, so current master might already be fixed. So please close again, if you can verify this behavior and feel free to open a new bug report.
I just did a bibisect and this was broken by: commit 4fc1b3fb659be916167518b49ffe8193e9033f30 Date: Tue Oct 26 09:15:17 2021 +0200 flatten ImplGetTextLines Let's see if I can spot the error in this…
Fix: https://gerrit.libreoffice.org/c/core/+/124557
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e78a519285a5d2ca5ccc9ae6a5fda81975fa38d7 tdf#145363 provide an explicit parent for numbering-style dialog It will be available in 7.3.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f4b353c1f52fc78a102413cac94c7fb24292bec6 Related: tdf#145363 provide an explicit parent for page format It will be available in 7.3.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.