Hello With Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6 I did not select the version because not included in the list at this time If you try to run the Web Page wizard, the wizard does not start and prevents closing Libreoffice. Steps to reproduce 1. File> Wizards> Web page Expected result: the wizard starts Actual result: the wizard don't start 2. File> Exit LibreOffice Expected result: exit libreoffice Actual result: libreoffice not closed You have to redo file> Exit to close (or Ctrl+Q) If you try to run x times the wizard, you need to do x+1 times "quit" to exit effectively. Regards Pierre-Yves
Hi Pierre-Yves, For point 1, same results with master LO 4.2.0.0.alpha0+ Build ID: 3e6853ae3e093b919ff3732e8fac05cb0a0fba5 on Windows 7 Home Premium On Point 2, close give the return to the start center, where I have to press the X icon the number of times I try to open the wizard to close LibreOffice. Jacques Guilleron
Hi Pierre-Yves, Could you try again after commit 11a560967f11f10ec570f665d0e65e17f124912a? I couldn't run the web wizard neither and this commit fixes it for me. Greetings
(In reply to comment #2) > Hi Pierre-Yves, > > Could you try again after commit 11a560967f11f10ec570f665d0e65e17f124912a? > I couldn't run the web wizard neither and this commit fixes it for me. > > Greetings hi, commit 11a560967f11f10ec570f665d0e65e17f124912a also works for me, even thogut the KeyExepction handling should not be the cause of the bug. Perhaps the missing import was the root cause. I'll investigate it.
I've build the tag libreoffice-4.1.0.0.beta2 on Linux x84 (Ununtu Quantal), with the following configure options: ./configure --with-system-libs -disable-kde --disable-kde4 --disable-kdeab --disable-epm --disable-gnome-vfs --disable-tde --disable-tdeab --disable-ext-wiki-publisher --disable-scripting-beanshell --disable-scripting-javascript --without-system-graphite --without-system-mdds --without-system-vigra --without-myspell-dicts --without-system-odbc --without-system-npapi-headers --without-system-sane --without-system-openldap --without-system-clucene --without-system-libmspub --without-system-libcmis --without-system-orcus --without-system-lpsolve --without-system-liblangtag --without-system-libmwaw --without-system-jfreereport --without-system-libodfgen --without-system-harfbuzz --without-system-mysql-cppconn --without-ppds --without-afms --without-krb5 --without-junit --without-gssapi --without-java --without-doxygen --srcdir=$HOME/libo.git --enable-option-checking=fatal I can't reproduce the bug on my build; the Web Wizard is launched as expected and I had no problems to close it. From #c1 I've understood that the test was performed on Window (the bug does not specify any platform); could it be a platform dependent issue ? Xisco, I've double ckecked my source code and the commit you mentioned is not applied, and the Web Wizard works as expected. What platform did you use to reproduce the bug ?
Hello (In reply to comment #4) > From #c1 I've understood that the test was performed on Window (the bug does > not specify any platform); could it be a platform dependent issue ? Yes the test was on windows 7 64bits, sorry for the omission... I tested and reproduced on same platform with: Version: 4.1.0.0.beta2+ Build ID: 509fa206b0f612d61740632c59351b69bbcfcad TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-06-13_12:35:41 New installation (new profile, registry cleaned). 1. The wizard do no start 2. It prevents closing in the same way (two launch testing = need three 'quit' to quit) Regards Pierre-Yves
Created attachment 80922 [details] Windows Process Monitor Log during Python Web Wizard execution - require SysInternals Process Monitor to view Confirm that on Windows install of LibreOffice 4.1.0 beta2+, that the Python Web Wizard does no bring up its dialog window. And that on exiting from LibreOffice, must exit a second time for close soffice.exe/soffice.bin processes. Windows 7 64-bit Version: 4.1.0.0.beta2+ Build ID: 5f58b80f7355f5947635d70b54b3e87a7421d8f TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-06-15_06:47:45 I have attached a Windows Process Monitor Log (.PML) of a LO launch, a File --> Wizards --> Web page... launch attempt, and the double exit. It has been filtered down to just the soffice.bin & soffice.exe processes and threads, debug details are present, but no symbols for the LibreOffice which probably is not too much of an issue. The python break actions are recorded, but as no "error" is thrown it is more a detailed execution log. =-=-= On same hardware, VMWare workstation instance of Linux Fedora 18 64-bit, the Web Wizard functions correctly in multiple builds of LO 4.1.0 beta2 Version: 4.1.0.0.beta2 Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6 2013-06-05 Version: 4.1.0.0.beta2+ Build ID: 9cf2d50ed5f53f5c40ce576c5bc370c18b9f67b TinderBox: Linux-x86_64@31-Release-Configuration-RHEL5-Baseline, Branch:libreoffice-4-1, Time: 2013-06-15_22:42:19
Thanks for the logs Stuart ! I wonder if (on windows) we can get console output somehow, if so we can turn on the built-in python debugging that may tell us something useful: program/pythonloader.py has a DEBUG=0 that could be DEBUG=1 to get more console output for python errors. similarly pythonscript.py needs a LogLevel.DEBUG setting. And then I suppose we need to tweak the build to get console output somehow (?) Failing that - I'm building myself.
(In reply to comment #7) >... turn on the built-in python debugging that may > tell us something useful: > > program/pythonloader.py > > has a DEBUG=0 that could be DEBUG=1 to get more console output for python > errors. > > similarly pythonscript.py needs a LogLevel.DEBUG setting. > Set the pythonscript.py to LogLevel.use = LogLevel.DEBUG # for script framework developers LOG_STDOUT = False # True, writes to stdout (difficult on windows) # False, writes to user/Scripts/python/log.txt Unfortunately, with Python debugging so set, writes to the default user/Scripts/python/log.txt do not occur under Windows builds. Not sure what else to try.
*** This bug has been marked as a duplicate of bug 68788 ***