Apache OpenOffice (AOO) Bugzilla – Issue 127154
Extension Manager hangs on macOS
Last modified: 2023-10-04 03:14:15 UTC
- with your browser, download any extension from the extension site - launch OpenOffice.app - in the Start Center press the Open button and browse to the directory where the extension was saved (by default, Downloads on your home directory) - the Extension Manager dialog opens, at the bottom it says "Adding <name of the extension .OXT file>" Bug: the Extension Manager seems to hang, it is impossible to close it Expected behavior: there should be an OK/Cancel dialog to proceed with the installation of the extension or cancel it Reproducible on Mac OS X El Capitan and macOS Sierra with 4.1.2
Another scenario: checking from updates hangs the Extension Manager - make sure you have at least one extension installed; if you can't install extensions in the user interface due to the bug described in Description, you can download an OXT from the extensions site and place it inside <path to>/OpenOffice.app/Contents/share/extensions/install/) - launch OpenOffice.app - Open menu Tools - Extensions Manager - on the Extensions Manager, press the Check for Updates... button. - the Extensions Manager hangs, it can't be closed, you have to force quit the application
Created attachment 86622 [details] Screenshot of hanging install window This problem is apparently still present in 4.1.6 on macOS High Sierra. I think the severity of this should be bumped up a bit.
Bug still present in 4.1.7 on macOS 10.15.4.
Is this also present in current builds from trunk?
It is at least still present in the 4.1.8 release.
(In reply to Kai-Mikael Jää-Aro from comment #5) > It is at least still present in the 4.1.8 release. That's why I updated "Last Confirmation in:" ;-)
Confirmed in both 4.1.8 and 4.2.0 dev from July. macOS - 10.15.7 With 4.2.0: I installed with an ODT open. It hung, but after force quite and just opening OpenOffice the extension was in place. I then checked for updates and it hung again.
BT of the thread: thread #5 frame #0: 0x00007fff6eabc882 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fff6eb7d425 libsystem_pthread.dylib`_pthread_cond_wait + 698 frame #2: 0x000000010865fdce libuno_sal.dylib.3`osl_waitCondition + 174 frame #3: 0x000000010a5ddf72 libvcl.dylib`AquaSalInstance::Yield(bool, bool) + 498 frame #4: 0x000000010a618a3b libvcl.dylib`Application::Yield(bool) + 91 frame #5: 0x000000010a820f46 libvcl.dylib`Dialog::Execute() + 102 frame #6: 0x0000000108c8328d libdeploymentgui.uno.dylib`dp_gui::ExtensionCmdQueue::Thread::_checkForUpdates(std::__1::vector<com::sun::star::uno::Reference<com::sun::star::deployment::XPackage>, std::__1::allocator<com::sun::star::uno::Reference<com::sun::star::deployment::XPackage> > > const&) + 141 frame #7: 0x0000000108c81e85 libdeploymentgui.uno.dylib`dp_gui::ExtensionCmdQueue::Thread::execute() + 757 frame #8: 0x0000000108c6c4da libdeploymentgui.uno.dylib`non-virtual thunk to dp_gui::Thread::run() + 26 frame #9: 0x00000001088905cf libsofficeapp.dylib`threadFunc + 15 frame #10: 0x0000000108663855 libuno_sal.dylib.3`___lldb_unnamed_symbol22$$libuno_sal.dylib.3 + 229 frame #11: 0x00007fff6eb7d109 libsystem_pthread.dylib`_pthread_start + 148 frame #12: 0x00007fff6eb78b8b libsystem_pthread.dylib`thread_start + 15
(In reply to Jim Jagielski from comment #8) > BT of the thread: This may be normal. What would help more is a stack trace of all threads together, eg. "thread apply all bt" in gdb.