Hi, I just tested last version 6.4.2.2... And now I have two extensions with wizards that no longer open... https://github.com/prrvchr/OAuth2OOo/blob/master/OAuth2OOo.oxt https://github.com/prrvchr/smtpMailerOOo/blob/master/smtpMailerOOo.oxt Can we know what has been changed in the Wizard service... Thanks
On pc Debian x86-64 with master sources updated today, I gave a try with OAuth200o.oxt and had en error message concerning Zip part. So I rename the oxt in zip (since odf files are zip) and tried to unzip it, here's the result: Archive: OAuth2OOo.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of OAuth2OOo.zip or OAuth2OOo.zip.zip, and cannot find OAuth2OOo.zip.ZIP, period. Idem for smtpMailerOOo.oxt Archive: smtpMailerOOo.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of smtpMailerOOo.zip or smtpMailerOOo.zip.zip, and cannot find smtpMailerOOo.zip.ZIP, period. Did you change the way to package oxt?
I workarounded the zip pb and for Oauth, I got this on console: warn:legacy.osl:12880:12880:desktop/source/deployment/manager/dp_manager.cxx:1247: Extension Manager: bundled and shared extensions must have an identifier and a version warn:desktop.deployment:12880:12880:desktop/source/deployment/registry/package/dp_package.cxx:1348: cannot create UCB Content for <file:///home/julien/lo/libreoffice/instdir/program/../share/uno_packages/cache/uno_packages/lu128fh8.tmp_/OAuth2OOo.oxt/META-INF/manifest.xml>
Forget my previous comments, when saving oxt files, it saved html pages with oxt extensions, I must test from scratch.
Ok I could install both extensions even if I noticed these logs on console: For OAuth2OOo.oxt warn:io.connector:15872:15941:io/source/connector/connector.cxx:97: Connector : couldn't connect to pipe af2aa4b4cea08373a418bd7ae4d74dcc162b11d52de42ba7bb9877b98c62d2(10) > accepting pipe,name=af2aa4b4cea08373a418bd7ae4d74dcc162b11d52de42ba7bb9877b98c62d2...connection established.warn:io.connector:15872:15941:io/source/connector/connector.cxx:97: Connector : couldn't connect to pipe f43f964870e26b7626a6e57ab92c795ce0b32dede3bb3bfb820c4b66a67a184(10) > accepting pipe,name=f43f964870e26b7626a6e57ab92c795ce0b32dede3bb3bfb820c4b66a67a184...connection established.warn:configmgr:15872:15941:configmgr/source/xcuparser.cxx:646: unknown property "Id" in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu146xe7.tmp/OptionsDialog.xcu" smtpMailerOOo.oxt warn:io.connector:15872:15941:io/source/connector/connector.cxx:97: Connector : couldn't connect to pipe 62f466fc7e1c7e215fce8429565de7e1bb6c5f8887a6b73ad5acfda4f686cf(10) > accepting pipe,name=62f466fc7e1c7e215fce8429565de7e1bb6c5f8887a6b73ad5acfda4f686cf...connection established.warn:configmgr:15872:15941:configmgr/source/xcuparser.cxx:646: unknown property "Id" in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu146xed.tmp/OptionsDialog.xcu" warn:io.connector:15872:15941:io/source/connector/connector.cxx:97: Connector : couldn't connect to pipe 9422eda05fbe6e5b6a363830c48d9be13c6e42b7fa7365e76f57de8f174bef3(10) > accepting pipe,name=9422eda05fbe6e5b6a363830c48d9be13c6e42b7fa7365e76f57de8f174bef3...connection established.warn:io.connector:15872:15941:io/source/connector/connector.cxx:97: Connector : couldn't connect to pipe 50fbe2b6872bf39f1ac1faab66b56baa7852ed9fba493c284a4eecb3998773d(10) > accepting pipe,name=50fbe2b6872bf39f1ac1faab66b56baa7852ed9fba493c284a4eecb3998773d...connection established
I saw both new entries in Tools/Options/Internet In Tools/Addons, I see smtpMailerOOo but I got this error: Python exception: <class 'RuntimeError'>: Type [] string is unknown, traceback follows File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unolib.py", line 46, in getPropertySetInfo properties = self._getPropertySetInfo() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 383, in _getPropertySetInfo properties['DataSources'] = getProperty('DataSources', '[] string', transient) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unotools.py", line 53, in getProperty property.Type = uno.getTypeByName(type) File "/home/julien/lo/libreoffice/instdir/program/uno.py", line 73, in getTypeByName return pyuno.getTypeByName(typeName) Python exception: <class 'RuntimeError'>: Type [] string is unknown, traceback follows File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unolib.py", line 46, in getPropertySetInfo properties = self._getPropertySetInfo() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 383, in _getPropertySetInfo properties['DataSources'] = getProperty('DataSources', '[] string', transient) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unotools.py", line 53, in getProperty property.Type = uno.getTypeByName(type) File "/home/julien/lo/libreoffice/instdir/program/uno.py", line 73, in getTypeByName return pyuno.getTypeByName(typeName) wizardpage.__init__() 1 warn:stoc:16405:16405:stoc/source/inspect/introspection.cxx:1612: object of type "com.sun.star.uno.XReference" lacks XTypeProvider warn:stoc:16405:16405:stoc/source/inspect/introspection.cxx:1612: object of type "com.sun.star.uno.XReference" lacks XTypeProvider Traceback (most recent call last): File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardpage.py", line 66, in __init__ self._refreshPage2() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardpage.py", line 191, in _refreshPage2 self._handler.refreshTables(self.Window.getControl('ListBox1')) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 259, in refreshTables table = self._query.UpdateTableName AttributeError: 'NoneType' object has no attribute 'UpdateTableName' Python exception: <class 'RuntimeError'>: Type [] string is unknown, traceback follows File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unolib.py", line 46, in getPropertySetInfo properties = self._getPropertySetInfo() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 383, in _getPropertySetInfo properties['DataSources'] = getProperty('DataSources', '[] string', transient) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unotools.py", line 53, in getProperty property.Type = uno.getTypeByName(type) File "/home/julien/lo/libreoffice/instdir/program/uno.py", line 73, in getTypeByName return pyuno.getTypeByName(typeName) Let's put this to NEW then. I can dig a bit but wonder if it could be due to Python3/2 compatibility.
Would it be possible you indicate with which max LO version it worked?
Stephan: taking a look at this error: Python exception: <class 'RuntimeError'>: Type [] string is unknown, traceback follows File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unolib.py", line 46, in getPropertySetInfo properties = self._getPropertySetInfo() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 383, in _getPropertySetInfo properties['DataSources'] = getProperty('DataSources', '[] string', transient) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unotools.py", line 53, in getProperty property.Type = uno.getTypeByName(type) File "/home/julien/lo/libreoffice/instdir/program/uno.py", line 73, in getTypeByName return pyuno.getTypeByName(typeName) I thought we could use this patch: diff --git a/cppu/source/typelib/typelib.cxx b/cppu/source/typelib/typelib.cxx index 92a7e6ca5120..b9f008365bcf 100644 --- a/cppu/source/typelib/typelib.cxx +++ b/cppu/source/typelib/typelib.cxx @@ -1906,6 +1906,7 @@ extern "C" void SAL_CALL typelib_typedescription_getByName( if (2 < name.getLength() && '[' == name[ 0 ]) { OUString element_name( name.copy( 2 ) ); + element_name = element_name.trim(); typelib_TypeDescription * element_td = nullptr; typelib_typedescription_getByName( &element_td, element_name.pData ); if (nullptr != element_td) What do you think? Is it ok or should the extension use "[]string" instead of "[] string" in this block 378 def _getPropertySetInfo(self): 379 properties = {} 380 readonly = uno.getConstantByName('com.sun.star.beans.PropertyAttribute.READONLY') 381 transient = uno.getConstantByName('com.sun.star.beans.PropertyAttribute.TRANSIENT') 382 properties['Connection'] = getProperty('Connection', 'com.sun.star.sdbc.XConnection', transient) 383 properties['DataSources'] = getProperty('DataSources', '[] string', transient) 384 properties['TableNames'] = getProperty('TableNames', '[] string', transient) 385 properties['ColumnNames'] = getProperty('ColumnNames', '[] string', transient) 386 return properties ? prrvchr: even after workarounding this pb, I got a new Python error, see console logs: wizardpage.__init__() 1 warn:stoc:17328:17328:stoc/source/inspect/introspection.cxx:1612: object of type "com.sun.star.uno.XReference" lacks XTypeProvider warn:stoc:17328:17328:stoc/source/inspect/introspection.cxx:1612: object of type "com.sun.star.uno.XReference" lacks XTypeProvider Traceback (most recent call last): File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardpage.py", line 66, in __init__ self._refreshPage2() File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardpage.py", line 191, in _refreshPage2 self._handler.refreshTables(self.Window.getControl('ListBox1')) File "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", line 259, in refreshTables table = self._query.UpdateTableName AttributeError: 'NoneType' object has no attribute 'UpdateTableName'
(In reply to Julien Nabet from comment #7) > Stephan: taking a look at this error: > Python exception: <class 'RuntimeError'>: Type [] string is unknown, > traceback follows > File > "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/ > lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unolib.py", line 46, in > getPropertySetInfo > properties = self._getPropertySetInfo() > File > "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/ > lu146xeb.tmp_/smtpMailerOOo.oxt/pythonpath/smtpmailer/wizardhandler.py", > line 383, in _getPropertySetInfo > properties['DataSources'] = getProperty('DataSources', '[] string', > transient) > File > "/home/julien/lo/libreoffice/instdir/user/uno_packages/cache/uno_packages/ > lu146xe6.tmp_/OAuth2OOo.oxt/pythonpath/unolib/unotools.py", line 53, in > getProperty > property.Type = uno.getTypeByName(type) > File "/home/julien/lo/libreoffice/instdir/program/uno.py", line 73, in > getTypeByName > return pyuno.getTypeByName(typeName) > > I thought we could use this patch: > diff --git a/cppu/source/typelib/typelib.cxx > b/cppu/source/typelib/typelib.cxx > index 92a7e6ca5120..b9f008365bcf 100644 > --- a/cppu/source/typelib/typelib.cxx > +++ b/cppu/source/typelib/typelib.cxx > @@ -1906,6 +1906,7 @@ extern "C" void SAL_CALL > typelib_typedescription_getByName( > if (2 < name.getLength() && '[' == name[ 0 ]) > { > OUString element_name( name.copy( 2 ) ); > + element_name = element_name.trim(); > typelib_TypeDescription * element_td = nullptr; > typelib_typedescription_getByName( &element_td, > element_name.pData ); > if (nullptr != element_td) > > What do you think? No, such errors should always be fixed on the calling side. There is a precise grammar for names of UNO type system entities (see <http://www.openoffice.org/udk/common/man/typesystem.html>), and we shouldn't second-guess what calling code actually meant.
Hi Julien, I did the update last night to confirm that the bug 125618 is still present on the latest version. If I look my package history I find: libreoffice-common (1:6.3.4-0ubuntu0.18.04.1~lo2) to 1:6.4.2-0ubuntu0.18.04.3 The previous version should be 6.3.4.x and everything was working properly. Do you have a particular setting to launch LibreOffice, so that it displays as many logs on console? Thanks
(In reply to Stephan Bergmann from comment #8) > ... > No, such errors should always be fixed on the calling side. There is a > precise grammar for names of UNO type system entities (see > <http://www.openoffice.org/udk/common/man/typesystem.html>), and we > shouldn't second-guess what calling code actually meant. Ok then, thank you Stephan for your quick feedback. prrvchr: so first thing is to change "[] string" to "[]string"
(In reply to prrvchr from comment #9) > Hi Julien, > > I did the update last night to confirm that the bug 125618 is still present > on the latest version. > > If I look my package history I find: > libreoffice-common (1:6.3.4-0ubuntu0.18.04.1~lo2) to 1:6.4.2-0ubuntu0.18.04.3 > . > The previous version should be 6.3.4.x and everything was working properly. Ok so there's something between 6.3.4 and 6.4.2. However, I wonder how come "[] string" could be ok before... > Do you have a particular setting to launch LibreOffice, so that it displays > as many logs on console? I build LO master sources locally with enable-dbgutil to have max logs.
Ok I changed [] string to []string But what I see is that the handlers are no longer called when a control is initialized (selection modified)
Well i'm not also sure about the handler, but the wizard advances on its own, we fall on the last page at the opening ...
Ok the handler executes correctly, but the WizardController executes createPage() on all the pages present in the ActivePath without checking by canAdvance() if the wizard can advance... I also have a serious display problem regarding the size of the Wizard...
In pythonpath/smtpmailer/dbqueries.py, I noticed a typo: # Get DataBase Version Query elif name == 'getVerion': query = 'Select DISTINCT DATABASE_VERSION() as "HSQL Version" From INFORMATION_SCHEMA.SYSTEM_TABLES' Shouldn't it be "getVersion" ?
hi Julien, Thanks for the typo, but I think this query is not used any more. Now I get the version via connection.getMetaData() which has the advantage of being independent of the database version unlike this query. I just went back to version 6.3.5.2 and I can confirm that the Wizard works well...
(In reply to prrvchr from comment #16) > hi Julien, > > Thanks for the typo, but I think this query is not used any more. > Now I get the version via connection.getMetaData() which has the advantage > of being independent of the database version unlike this query. > > I just went back to version 6.3.5.2 and I can confirm that the Wizard works > well... In this case, just remove it. Could you provide last steps you tried where it failed? In //, you may be interested in retrieving LO sources and build LO. It allows to control precisely the options. In autogen.input I would include these: --enable-python=fully-internal (to be sure it's full compatible with Python used by LO) and --enable-dbgutil (for having max debug info). Of course, it'll take lots of space (About 30/35Gb) + dependencies. You may also try daily builds, https://dev-builds.libreoffice.org/daily/master/ but you can't add some extra traces in LO and you still got to manage dependencies. For the rest, I can't tell. If I were you, I'd retrieve LO sources and would build LO following:
I wish I could build LO, but I think my laptop is too old (512MB Ram, small DD), maybe soon ... I think I will stay under 6.3.5.2 and wait for the replacement for 6.4.2.2
I just did tests under 6.4.3.2, I have the same problems, namely the Wizard which no longer works. This problem seems to be related to the 6.4.X branch since I no longer have a functional Wizard since this version. I find this more than worrying ...
(In reply to prrvchr from comment #19) > I just did tests under 6.4.3.2, I have the same problems, namely the Wizard > which no longer works. > This problem seems to be related to the 6.4.X branch since I no longer have > a functional Wizard since this version. > I find this more than worrying ... A bit early to tell this. Have you got new oxt with "[]string" + typo fix for "getVersion"? Still waiting for "last steps you tried where it failed" indicated in my previous comment. Finally, did you build LO sources?
(In reply to Julien Nabet from comment #20) > Have you got new oxt with "[]string" + typo fix for "getVersion"? it's done as said in my comment #12 > Still waiting for "last steps you tried where it failed" indicated in my previous comment. Wizard does not display pages correctly The Wizard advances alone The Wizard browser (left part) is only partially visible > Finally, did you build LO sources? I would love to, but I can't ...
> This problem seems to be related to the 6.4.X branch > since I no longer have a functional Wizard since this version. Changes have been made to the wizard with version 6.4.X (new look of the wizard browser) and I think we should review these changes, because it is from these changes that it no longer works
(In reply to Julien Nabet from comment #20) > Still waiting for "last steps you tried where it failed" indicated in my previous comment. I just had time to redo tests under 6.4.3.2. here is what it stands out: - When launching the Wizard by XWizard.execute() all pages are created (XWizardController.createPage() is called for all pages of the path)!!! Normally the pages are created as you navigate the wizard and if possible (XWizardPage.canAdvance() and XWizardController.canAdvance() are true) - If we manage to load the page, it appears as if it was disabled (all controls are grayed out ...) and it is not possible to activate it (XWizard.enablePage() has no effect) - In addition, the size of the pages is no longer taken into account, the Wizard being displayed with a fixed size. Voila, I hope this will allow us to move forward... I will have to reinstall 6.3.x if I want to be able to continue...
Hi, I just did tests with version 7.0.0.0.alpha1, we have the same problem as under 6.4.x, the Wizard service is broken...
can't help here=> uncc myself
> can't help here=> uncc myself what to understand?
Hi, This problem is solved for me: I rewrote the Wizard service as an interface: https://github.com/prrvchr/OAuth2OOo/blob/master/python/wizard.py I even corrected the bugs 132661 and 132666. On the other hand, I am surprised at your ineffectiveness in resolving a regression that appeared with version 6.4.x and which will surely still be present with version 7.x From now on, I won't waste time reporting bugs ... Can't help more here => uncc myself
Dear prrvchr, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This can be tested by installing a version of the OAuth2OOo extension prior to the custom wizard was added to it: https://github.com/prrvchr/OAuth2OOo/releases/tag/v0.0.4 Then going to Tools > Options > Internet > OAuth2 protocol > OAuth2 wizard. Repro: Version: 6.4.7.2 Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b52117c0be97c45824d2897657084f8ac7e9bf42 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded No repro: Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
Bibisected with linux-64-6.4 repo to first bad commit 425f162ab1ecf661392aead48995fb58583e4b85 which points to core commit: commit 910b8b04325e0103941b6c6d152e4ee5f0388fc2 author Caolán McNamara <caolanm@redhat.com> Sun Sep 15 17:42:39 2019 +0100 committer Caolán McNamara <caolanm@redhat.com> Fri Sep 20 21:24:06 2019 +0200 tree 6e6422b6482f85c67b32b3f304db220eb78fadf7 parent ca7c24dafe7aba7c2d71994d2561f1ae3d59257e make WizardShell use RoadmapWizardMachine Change-Id: Id7e1e163f17cd4866c37bbd6cad73b8c721f4dae Reviewed-on: https://gerrit.libreoffice.org/78969 Caolán, what are your thoughts?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cdf7b51229f2353376fb4e9de309fb9ee5580b3a tdf#132110 page ids might not be state ids It will be available in 7.6.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 "libreoffice-7-5": https://git.libreoffice.org/core/commit/e7dd0fa490c671267a4419a6c2ef8a1367114209 tdf#132110 page ids might not be state ids It will be available in 7.5.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9c978e4c75e342b2345ff4fcbd1b5751627d8baf Related: tdf#132110 use the container child size as default size It will be available in 7.6.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.
That fixes the steps of the wizard and the size of the wizard. Seems to be ok in trunk now, backports to 7-5 in gerrit. Won't backport to earlier.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b428a97d88b08fadd63039482c09c17a5fbac3be Related: tdf#152508 and tdf#132110 use initial child size as size request It will be available in 7.6.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.
Ilhan Yesil committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/f933248c042e6fa8ed29daf19fd8bba47a5cc3d6 Related: tdf#132110 use the container child size as default size It will be available in 7.5.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.
I don't want to discourage you, but for me the Wizard is still unusable. I produced a test case see issue 132666: https://bugs.documentfoundation.org/show_bug.cgi?id=132666