Using a section and hiding it depending on the value of a variable doesn't work any more. After changing the variable back and forth, it looks as if the condition would be overwritten. To test this: - open a new empty document - add a hidden variable ('hide') and set it to 0 - add a section ('section1') below and enter some text - edit the section: - mark 'hide with condition' - add the condition 'hide == 1' - change the variable 'hide' to 1 (section1 will disapper) - change the variable 'hide' to 0 (section will re-appear) From this point on, for me the condition is just set to 0. Changing 'hide' no longer has any effect on the section.
Hello I confirm this bug and I can add some precisions. Steps to reproduce 1. Open the attached document (HiddenSection.odt) (it contains 4 colored sections to see the sections but color not involved in the problem) Displaying these sections is conditionned by the value of a variable named "Hide". All sections have the same condition. 2. Do Format> Sections to check the condition for each section. The expected result is shown in HideSection.png screenshot. 3.Double-click "No" (or right click> Fields) in the first paragraph then change the value from No to Yes Expected Result: all hidden sections Actual result: the last section is not hidden Format> Sections> Section4> Hide is always selected but condition has become 0 (zero). Note: the problem is always the *last* section of the document (checked with 2, 3, 4). Reproduced (fr-discuss) with: Windows XP & LibO 3.6.2.1 Windows 7 & LibO 3.6.2.1, LibO 3.6.5, 4.0.0.3, 4.1.0.0.alpha0+ Windows 7 Home Premium & LOdev 4.0.1.0+ Note, this bug is *not* reproduced with: WinXP sp3 & LibO 3.3.4, LibO 3.5.2, LibO 3.6.0.4 So Regression occurred between 3.6.0.4 and 3.6.2.1 Regards Pierre-Yves
Created attachment 74638 [details] HideSection.png screenshot (show condition before the bug)
Created attachment 74640 [details] HiddenSection.odt
*** Bug 59059 has been marked as a duplicate of this bug. ***
I can confirm this bug also with later 3.5.x versions. Hiding sections works in 3.5.2 and 3.5.5, it does not work in 3.5.7! This makes many templates in companies unusable.
With Att. "2013-02-11 18:44 UTC, pierre-yves samyn ": Already [Reproducible] with * server installation of "LibreOffice 3.5.7.2 German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) Was still ok with * Server installation (own profile) of "LibreOffice 3.5.6.2 German UI/Locale [Build-ID: e0fbe70-5879838-a0745b0-0cd1158-638b327] on German WIN7 Home Premium (64bit) * Server installation 3.5.3.1 Bodo UI * Various more early 3.5 So currently it seems that started between 3.5.6.2 and 3.5.7.2
Still a problem on 4.0.0.3 release on Bodhi Linux Bibisect 3959ee48f25552210657c68840918bc9d0d3b310 is the first bad commit commit 3959ee48f25552210657c68840918bc9d0d3b310 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 06:37:06 2012 +0000 source-hash-57c3b583f1f69edd32b2a54253850e1b3b202255 commit 57c3b583f1f69edd32b2a54253850e1b3b202255 Author: Eike Rathke <erack@redhat.com> AuthorDate: Sat Aug 11 13:49:25 2012 +0200 Commit: Eike Rathke <erack@redhat.com> CommitDate: Sat Aug 11 13:49:30 2012 +0200 langtag: libxml2 only used for liblangtag Change-Id: I4bf7bc4f58bac7675cf694dc206e6ba119a6354e # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # bad: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect bad f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # good: [5bf3b624cdeb593e55402f44c730209f12813961] source-hash-4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7 git bisect good 5bf3b624cdeb593e55402f44c730209f12813961 # good: [70771b69f427dcd3ace8caea819338f104b88c43] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435 git bisect good 70771b69f427dcd3ace8caea819338f104b88c43 # bad: [3959ee48f25552210657c68840918bc9d0d3b310] source-hash-57c3b583f1f69edd32b2a54253850e1b3b202255 git bisect bad 3959ee48f25552210657c68840918bc9d0d3b310
Jacqueline showed me that bug on CeBIT.
Most probably bb6bd1ff9cd3eecec7eb2cd7bd0a4dcef584c903, the better question is how to fix this without reverting, and this introducing the original bug again. :-)
Hi Miklos, great news! That was really quickly ;-) Thank you very much also from Jacqueline (here on LibreOffice booth at CeBIT, Hannover ;-) The question is because that is a really severe bug, that makes LO for many customers unusable (Jacqueline told me that) for all version starting with 3.5.7 i would suggest to immediately revert it at least for all release branches (latest 3.6.X release branch). What do you mean? Thanks David
So, i now better understand the problem: the bb6bd1ff9cd3eecec7eb2cd7bd0a4dcef584c903 fixes writer crash: if all sections are hidden, writer crashed. So to prevent that bb6bd1ff9cd3eecec7eb2cd7bd0a4dcef584c903 only hides n-1 sections, and overwrite the condition in the last section to prevent it to be heeden and writer to crash. So a short term solution/possible workaround for would be to define n+1 sections: n real section and a dummy (invisible) one in the document. When the variable is changed, the n real section are hidden or shown, and the dummy one get overwritten. Mid term solution would be to fix the crash in the right way.
Exactly, just reverting the commit would introduce a crash, so it's a no-go. A better fix would be checking if there are paragraph outside the sections -- if there is at least one, even the last section can be deleted.
Sorry, I mean: deleted from the layout, hidden from the document model.
If there are no paragraphs outside the sections, wouldn't it be better to add an empty paragraph instead of changing the condition in the last section? At least you should not change the condition itself, but only deactivate the option "hide".
(In reply to comment #12) > Exactly, just reverting the commit would introduce a crash, so it's a no-go. > No crash seems to happen any more after reverting it: https://gerrit.libreoffice.org/#/c/2613/
Still crashes here after the revert: #0 0x00007fcd438f367c in SwFrm::GetUpper (this=0x0) at /home/vmiklos/git/libreoffice/master/sw/source/core/inc/frame.hxx:596 #1 0x00007fcd43d1142f in SetLastPage (pPage=0x0) at /home/vmiklos/git/libreoffice/master/sw/source/core/layout/pagechg.cxx:877 #2 0x00007fcd43d0c5a6 in SwPageFrm::Cut (this=0x3418d10) at /home/vmiklos/git/libreoffice/master/sw/source/core/layout/pagechg.cxx:937 #3 0x00007fcd43d0e154 in SwRootFrm::RemoveSuperfluous (this=0x3417fc0) at /home/vmiklos/git/libreoffice/master/sw/source/core/layout/pagechg.cxx:1531 #4 0x00007fcd43ce2d2b in SwLayAction::InternalAction (this=0x7fff164dfaa0) at /home/vmiklos/git/libreoffice/master/sw/source/core/layout/layact.cxx:620 Jacqueline: you're right, adding a simple new paragraph to the end of the doc would be indeed a solution, I think.
(In reply to comment #16) > Still crashes here after the revert: > > #0 0x00007fcd438f367c in SwFrm::GetUpper (this=0x0) at > /home/vmiklos/git/libreoffice/master/sw/source/core/inc/frame.hxx:596 on current master? weird, why it doesn't crash here? I will send you my test document.
Master, built from scratch today (Linux, x86_64 -- but that hardly matters). I used the original bugdoc from bug 53210, and the instructions from https://bugs.freedesktop.org/show_bug.cgi?id=53210#c5
(In reply to comment #18) > Master, built from scratch today (Linux, x86_64 -- but that hardly matters). > I used the original bugdoc from bug 53210, and the instructions from > https://bugs.freedesktop.org/show_bug.cgi?id=53210#c5 Yes, can reproduce it now. With this document it indeed crashes. So what is the difference? Why it doesn't crash with my simple test? There i also don't have any paragraph outside the last section, if this matters?
(In reply to comment #16) > Still crashes here after the revert: > > [...] > Jacqueline: you're right, adding a simple new paragraph to the end of the > doc would be indeed a solution, I think. Hmm, doesn't look like that: 1. Open the attached document 2. Go to the end of document 3. You are in the last section 4. Type Alt + Enter, to create one new line outside the last section 5. Ctrl + F2 and set all vars to 0 like described above 6. F9 (Tools => Update) 7. Crash doesn't happen with reverted version, all section invisible 8. Type some Ctrl + Z (undo) to delete last charachter (new line outside the last section) => writer crashes again
I tested the document from bug 53210 with an older LibO-Version without the patch: The crash only occurs, if you update all sections at one time, if you change the values of the user fields to 0 and update the sections step by step, no crash occurs. Then you get the expected result: The option "hide" in the last section is deactivated. So maybe the real cause can be found there, where the "update all" mechanisn is.
(In reply to comment #20) > 7. Crash doesn't happen with reverted version, all section invisible > 8. Type some Ctrl + Z (undo) to delete last charachter (new line outside the > last section) => writer crashes again This seams to me explainable, because the step before inserting the new paragraph is "update-all" -> crash, see my comment 21
David Ostrovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1bf65d1d57856491431fdb4b90f5a228ee592da1 fdo#55814 create unit test for it first The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Following the bug description, there is a non-section paragraph at the end of the document. A simple fix is to check if the last paragraph in the document is part of a section, and if not, don't do the fix for bug 53210.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62344016de056965a58ea2016d912a68eac0d6b0 fdo#55814 SwDoc::UpdateExpFlds: hiding the last section may be safe The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Miklos thank you for your fix! Reading it // Is the last node part of a section? + SwPaM aPam(GetNodes()); + aPam.Move(fnMoveForward, fnGoDoc); + if (aPam.Start()->nNode.GetNode().StartOfSectionNode()->IsSectionNode()) + { [...] i am afraid that the instructions from comment #20 would lead to LO crash now: https://bugs.freedesktop.org/show_bug.cgi?id=55814#c20 right?
David, That's indeed an issue. But that never worked (OOo 3.3 crashes in that case as well), so I would create a separate non-regression bug for that. Thanks, Miklos
-4-0 review: https://gerrit.libreoffice.org/2876
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=326be48e3e3edd151e59abbafac6c70077296675&h=libreoffice-4-0 fdo#55814 SwDoc::UpdateExpFlds: hiding the last section may be safe It will be available in LibreOffice 4.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
David Ostrovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3333bb59e2e22161fcf66e3c71f58f5b160a24c9 fdo#55814 improve unit test The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
-3-6 review: https://gerrit.libreoffice.org/2901
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=75e7e130448182c15697c8dd0b8d50324db4f79f&h=libreoffice-3-6 fdo#55814 SwDoc::UpdateExpFlds: hiding the last section may be safe It will be available in LibreOffice 3.6.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello WRKSFORME with Windows 7 64bits & Version 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39) Thank you Regards Pierre-Yves
David Ostrovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c0a9bb59ed19b2f4492defd84d023c5e169d777 fdo#55814 migrate java unit test to python The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This fix is buggy as well, but not quite as critical. I noticed this bug in LO 4.1.0.4 from Debian unstable when the last node in the document was a hidden section. None of the others are. I was able to work around the current bug by adding an empty paragraph after the hidden section. I'm not quite sure whether I shoud create a new bug report for the buggy patch. In general, the patch should not only check the last node.