Steps: 1) Open LO 2) Open Tools > Options > Load/Save > General and set autosave to 1 min 3) Open https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt 4) Autosave happens after 1 minute though the document wasnt modified 5) Once autosave completes, the undo split button is filled with 'change style' entries. This doesnt happen in 5.0 daily. Version: 5.1.0.0.alpha1+ Build ID: f6bc5b79c31225c02e9500d0ced4bd26f998f82b TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-11-24_01:06:28 Locale: en-US (en_US.UTF-8)
I only have "Save autorecovery.." and no autosave option. Setting autorecovery to 1 min and restarting LibO does not give the effect you see with GS42-GettingStartedLO.odt Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a7c3a2a9be83686657c06f37d521f9f6d2004ddd Threads 4; Ver: Windows 6.1; Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2015-11-28_04:39:18 Locale: fi-FI (fi_FI)
Autosave option has been made hidden since LO 5.0. Search autosave in expert configuration to change its value. See bug 65509 Please, could you test with a clean new user profile? Best regards. JBF
(In reply to Beluga from comment #1) > I only have "Save autorecovery.." and no autosave option. Yes autosave meant save autorecovery. :D
I can not confirm with Version: 5.2.0.0.alpha0+; win7. Jay, could you retest with actual version? Thanks
Still happening with cleared profile. Maybe someone should test it on Linux to see if its a Linux-only bug. Version: 5.2.0.0.alpha0+ Build ID: b19ac3c4c6b4a41a1f3acac68b299fd676428a87 CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-04-21_08:41:08 Locale: en-US (en_US.UTF-8)
Not reproduced. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 29c4f7bd5863e34c449062aca6f8aee5ec7510a2 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 28th 2016
@stuart, @cor, @heiko: can any of you reproduce this?
After 4) nothing happens unless I agree with "Edit document" (notification panel at top since the file was downloaded from a suspicious place). After that 5) happens (undo change style). Not sure if this behavior is really unexpected. Version: 5.1.2.2.0+ Build ID: 5.1.2.2 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: de-DE (de_DE.UTF8)
Addendum: It takes about 6 seconds on my system until the undo is enabled after opening the document. Guess this time is needed to parse through the entire document. Meaning also that I always have to agree to close without saving changes. Even after 10 seconds.
"Edit document" .. you opened it straight from the browser without downloading first. Try downloading fully and only then opening.
(In reply to Buovjaga from comment #10) > Try downloading fully and only then opening. Read my second comment.
For me GettingStartedLO.odt more or less freezes with Version: 5.2.0.0.alpha1+ Build ID: fe2bf7b05936bb3e84ccc5ddc3dad865a22de551 CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-04-27_00:55:13 Locale: nl-NL (nl_NL.UTF-8) .. (not really, but working is not possible at all..)
Setting to new as Heiko confirmed the undo. @Heiko: I also noticed that at one point even before the undo button became active, that if i closed the document it also showed save changes dialog. @Cor: Yep my 2 cpu cores get hammered (> 90%) until it fully loads the 800+ page file, but luckily the UI doesnt freeze for me.
the problem is caused by this call in SwDrawContact::Changed_() GetFmt()->GetDoc()->SetFlyFrmAttr( *(GetFmt()), aSet ); this is called during layout and changes the document model, setting the modified status in the document. it also creates the "Changed style" undo entries. the AutoRecovery save happens because the document was set to modified. this code is there since 2004, f830588605badb9c1b2e43567f4de558db7a601c so it's not obvious why this bug would be a regression. i'm very surprised that the layout does something like this, very odd...
something about the number of pages after initial load; if you get 396 pages you never get a undo action, if you get ~580 or ~810 pages you get them ... bisected, regression from: commit b4b7703e4335460cf48bfd6440f116359994c8ff Author: Noel Grandin <noelgrandin@gmail.com> AuthorDate: Wed Oct 14 02:51:05 2015 +0200 cppcheck:variableScope ... which causes the layout-cache that is stored in the document to restore a lot more pages than 396. fixed on master note that in general it's still possible that documents end up modified by the code mentioned in comment #14, that cannot be prevented currently
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c488214817516c13603deb1c180fef02f4c700bf tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_() It will be available in 5.3.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=905e38c7c6c02ec618b9231545c45debba3a8a44&h=libreoffice-5-2 tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_() It will be available in 5.2.0.1. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=95ed42cc9f9cd40503ca609f1bcad31c5298889b&h=libreoffice-5-1 tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_() It will be available in 5.1.5. 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.
*** Bug 99590 has been marked as a duplicate of this bug. ***
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a73629cf36a484d58aba74057bacdf04d4728599&h=libreoffice-5-1-4 tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_() It will be available in 5.1.4. 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.