Files based on templates with fields crash every time we click on "next" to fill the next field. We still can work on the file. An example of the kind of files and fields here: http://templates.libreoffice.org/template-center/lettre-avec-entetes-et-champs-de-saisie-et-suite-de-lettre
TESTING with LO 4.4.0.3 + Ubuntu 14.04 (In reply to Ysabeau from comment #0) > Files based on templates with fields crash every time we click on "next" to > fill the next field. > We still can work on the file. > > An example of the kind of files and fields here: > > http://templates.libreoffice.org/template-center/lettre-avec-entetes-et- > champs-de-saisie-et-suite-de-lettre 1) Open the template in LibreOffice Specifically, this file: http://templates.libreoffice.org/template-center/lettre-avec-entetes-et-champs-de-saisie-et-suite-de-lettre/releases/2.None/id-modele-lettre-entete-styles-champs.ott 2) Replace "nom" with "walrus" 3) Click 'Next' button 4) Wait a few seconds ...and CRASH! Status -> NEW
TESTING with Ubuntu 14.04 + LO Version: 4.5.0.0.alpha0+ Build ID: 84c69550bcb8139669de9cf98b51c35f21fe853d TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-13_08:44:23 Locale: en_US (In reply to Robinson Tryon (qubit) from comment #1) > 1) Open the template in LibreOffice > > Specifically, this file: > http://templates.libreoffice.org/template-center/lettre-avec-entetes-et- > champs-de-saisie-et-suite-de-lettre/releases/2.None/id-modele-lettre-entete- > styles-champs.ott > > 2) Replace "nom" with "walrus" > 3) Click 'Next' button > 4) Wait a few seconds > > ...and CRASH! NOREPRO with 4.5-master (version above) Status -> RESOLVED WORKSFORME Whiteboard -> backportRequest:4.4
@Robinson, * How can you Resolve WFM on 4.4 if we do not know the commit in master that fixed this? Is it not still a valid, and active bug on 4.4?
(In reply to V Stuart Foote from comment #3) > @Robinson, * > > How can you Resolve WFM on 4.4 if we do not know the commit in master that > fixed this? Is it not still a valid, and active bug on 4.4? The bug is fixed in a later version (master branch), so we mark it as such. But we can backport it to a release branch. Note that it's tagged: - backportRequest to the 4.4 branch - bibisectRequest (this will be a reverse-bibisect, to find the commit that fixed it) More info here: http://lists.freedesktop.org/archives/libreoffice-qa/2015-January/008335.html https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#Fixed_in_a_newer_version
Confirming a valid <Ctrl><Shift>+<F9> input field edit -- which the template opens on launch as a new document--behaves correctly with current builds of master. Windows 7 sp1, 64-bit en-US with Version: 4.5.0.0.alpha0+ Build ID: 4b9a9ce8a0e5e0716dad9a9ec87d16237e534dc2 TinderBox: Win-x86@39, Branch:master, Time: 2015-01-31_09:49:44 Locale: en_US But, in 4.4.0.3 it also behaves (no crash) when editing the field description if the template based document is simply saved once as a new document. =-=-= QA Administrivia... Regards resolving WFM, guess that is OK if that is the QA consensus. But the logic escapes me then of even retaining MABs (or tracking Metas). If a bug shows as resolved in the MAB listing (or any tracking Meta)--it does not get further reviewed--and then we have to drag BZ for the issues. Which then requires an advanced query against Whiteboard field to match regular expression "backportRequest" or similar strings. With 4.4.0 just out of the gate, valid new MABs are going to bubble up against the branch--I just don't see a reason to close them so quickly and then to depend on someone doing a "reverse" bibisect and back-port requests. Which can't even be done for OS X or Windows issues.
I do not reproduce the crash anymore with current build of version 4.4.1.0.0+. I am currently verifying that the following commit fix the issue for 4.4 branch : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=092a73d070e05f54990151fdc4e66e8adac8097d Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #6) > I do not reproduce the crash anymore with current build of version > 4.4.1.0.0+. I am currently verifying that the following commit fix the issue > for 4.4 branch : > > https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff; > h=092a73d070e05f54990151fdc4e66e8adac8097d > I confirm, without this commit LO 4.4.1.0.0+ the crash is reproducible, with the commit it is not. Set status accordingly. Best regards. JBF