Description: We're developing a LibreOffice extension using Python. We've done a basic framework and it can be installed in LibreOffice. However it only works when VCLPLUGIN=gtk3. When using VCLPLUGIN=kf5, it would show nothing and would just hang there, accepting no input anymore. The extension code is at: https://github.com/libreofficeid/LO-TC-GUI and the extension oxt file will be attached later. Steps to Reproduce: 1. Install the oxt file built by the code providing above. 2. In Tools->Addons, run the extension 3. Nothing will be shown and the whole LibreOffice would be stuck there Actual Results: Nothing will be shown and the whole LibreOffice would be stuck there Expected Results: It should show a dialog named Theme Changer. Reproducible: Always User Profile Reset: No Additional Info: My LibreOffice version is: 版本：6.4.0.0.alpha1 組建 ID：cc57df8f942f239d29cb575ea5a7cb01405db787 CPU 執行緒：4; OS：Linux 5.2; UI 算繪：預設; VCL: kf5; 語言地區：zh-TW (zh_TW.UTF-8); UI-Language: zh-TW Calc: threaded
Created attachment 155701 [details] Extension file
Created attachment 155710 [details] bt with debug symbols (kf5) On pc Debian x86-64 with master sources updated today, I don't reproduce the crash at this moment but when closing LO (with kf5 + gen, not with gtk3)
I repro the stuckness. Arch Linux 64-bit Version: 6.4.0.0.alpha1+ Build ID: 24f17f0336badfbba276c1e6713a89b4f9bb7cb8 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 11 November 2019
(In reply to Julien Nabet from comment #2) > Created attachment 155710 [details] > bt with debug symbols (kf5) > > On pc Debian x86-64 with master sources updated today, I don't reproduce the > crash at this moment but when closing LO (with kf5 + gen, not with gtk3) Please open a new bug report. This is about an extension dead- or life-locking LO in the kf5 and gen backend. Your bug is some broken VclPtr handling, which triggers an assertion in debug builds.
This is basically a duplicate of bug 121293. That bug was "fixed" by adapting the presentation minimizer extension, so it won't trigger the "Show, Hide, SetModal, Show" code path. Easily done, as the setVisible(True), before the execute() in the showDialog() python call in the extension, is not needed. The original, but later removed workaround (to sleep 250ms after the Hide in SetModal) also still works (that was commit e770bacc85a0eec96de77068d61b03f374b3cdec). I couldn't find and fix the real bug back then. The underlying problem is the non-mapped modal main window of the extension, which blocks LO, even if it's invisible (you can see the unmapped window state of it with "xwininfo -name MainDialog", if you're curious). So I wasn't very optimistic after finding all this, but OTOH this is like fresh start on an old bug and I had a very crude workaround at hand, if all failed. So now I'm even more happy to present a non-workaround fix: https://gerrit.libreoffice.org/82745 And BTW: while looking into bug 121293 I found a resource leak in the minimizer, which also affect your extension. If you call xDialog->createPeer(xToolkit, ...), you need to explicitly free that resource later by calling the equivalent of Reference<XComponent> xDialogComponent(xDialog, UNO_QUERY_THROW); xDialogComponent->dispose(); probably in the python __exit__ function of your dialog. You can see the leak by calling "xwininfo -root -tree | grep children" after opening and closing your dialog. You'll see the number of children growing +1 per opened and closed dialog. This is actually documented somewhere in the OOo UNO dialog development wiki pages, but still it took me quite some time to understand the origin of that leakage back then.
(In reply to Jan-Marek Glogowski from comment #5) > So I wasn't very optimistic after finding all this, but OTOH this is like > fresh start on an old bug and I had a very crude workaround at hand, if all > failed. So now I'm even more happy to present a non-workaround fix: > https://gerrit.libreoffice.org/82745 Built with the patch and stuckness is gone. Thanks!
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5d23f7748f33414a95297fa9f374a37e76de687b tdf#128710 Qt5 don't force immediate paint on show It will be available in 6.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.
Set VERIFIED FIXED from comment 6. Backports are on their way.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/876303943113bb7fa09c3b344a832f714ac2d8e3 tdf#128710 Qt5 don't force immediate paint on show It will be available in 6.4.0.1. 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 "libreoffice-6-3": https://git.libreoffice.org/core/commit/02c056b071f95257bd09b7fdfa479bff97bc33dc tdf#128710 Qt5 don't force immediate paint on show It will be available in 6.3.4. 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 156116 [details] Extension file (Nov. 26) Test under: Version: 6.4.0.0.beta1 Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: zh-TW (zh_TW.UTF-8); UI-Language: en-US Calc: threaded The extension can be shown, but would still hang randomly. Sometimes it would hang when launching; sometimes hang when clicking a button like Create or Import. When hanging I can still move and change the window size, just nothing happens when clicking on any button, even the window closing x button.
(In reply to Franklin Weng from comment #11) > Created attachment 156116 [details] > Extension file (Nov. 26) > > Test under: > > Version: 6.4.0.0.beta1 > Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 > CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: kf5; > Locale: zh-TW (zh_TW.UTF-8); UI-Language: en-US > Calc: threaded > > > The extension can be shown, but would still hang randomly. Sometimes it > would hang when launching; sometimes hang when clicking a button like Create > or Import. > > When hanging I can still move and change the window size, just nothing > happens when clicking on any button, even the window closing x button. And again, everything is okay under VCLPLUGIN=gtk3
(In reply to Franklin Weng from comment #11) > Created attachment 156116 [details] > Extension file (Nov. 26) > > Test under: > > Version: 6.4.0.0.beta1 > Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 > CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: kf5; > Locale: zh-TW (zh_TW.UTF-8); UI-Language: en-US > Calc: threaded > > > The extension can be shown, but would still hang randomly. Sometimes it > would hang when launching; sometimes hang when clicking a button like Create > or Import. > > When hanging I can still move and change the window size, just nothing > happens when clicking on any button, even the window closing x button. I installed the new extension, but no hang for me Arch Linux 64-bit Version: 6.5.0.0.alpha0+ Build ID: 5f0db2c24c466e3c4cf0dc8faba1c62b38c770fd CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 27 November 2019
Created attachment 156320 [details] ThemeChanger extension (Dec. 5) It still happen randomly. Click create, cancel, import, cancel, try import themes located in git repository, ... it would eventually hangs.
Is this still reproducible with a current daily build of master? (In reply to Franklin Weng from comment #14) > It still happen randomly. Click create, cancel, import, cancel, try import > themes located in git repository, ... it would eventually hangs. To narrow this down a bit: Can you reduce the amount of different steps taken, e.g. does it also happen if you just click "Create" and "Cancel" one after the other all of the time?
(In reply to Michael Weghorn from comment #15) > Is this still reproducible with a current daily build of master? > > (In reply to Franklin Weng from comment #14) > > It still happen randomly. Click create, cancel, import, cancel, try import > > themes located in git repository, ... it would eventually hangs. > > To narrow this down a bit: Can you reduce the amount of different steps > taken, e.g. does it also happen if you just click "Create" and "Cancel" one > after the other all of the time? Not reproducible in 版本：6.4.3.2 組建 ID：747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU 執行緒：4; OS：Linux 5.4; UI 算繪：預設; VCL: kf5; 語言地區：zh-TW (zh_TW.UTF-8); 介面語言：zh-TW Calc: threaded Set to WORKSFORME.