Created attachment 61198 [details] Screenshot of corrupted Presentation Document Using LibreOffice 3.5.2.2 Build ID: 350m1(Build:202) in Impress on Ubuntu 12.04 LTS. If I press F7 or use the menus to open Spell check it scans (without picking up any errors, but that is another matter, probably because it needs English Australia). Then it states it has scanned to the end of the document and whether you want to scan from the beginning, if you say 'No' all is good, but 'Yes' results in the entire document being replaced with some random document. Undo does nothing, had to close and re-open to fall-back to my last save. Went from ~ 50 slides to 2. (As in attachment)
Created attachment 61205 [details] Screenshot of Impress before choosing an option at search prompt. When the prompt 'LibreOffice Impress has searched to the end of the presentation. Do you want to continue at the beginning?' the screen behind it gets replaced with an unusual empty template. This screen disappears if I click 'No' but the entire document gets replaced if I click 'Yes'.
Amendment: This appears to be a bug in the 'Find' function, as the corruption occurs even when doing normal searches for text. I don't believe this to be a problem with the spell check function itself.
BUG Still exists in LibreOffice 3.5.3 (Using latest version from libreoffice.org) LibreOffice 3.5.3.2 Build ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b8 BUG still effects 'Ctrl+F' if you search for something and if you don't find it in the document and it then asks to search from the beginning. If it finds it before the end the bug is prevented. If you search from the start of the document the first time, the prompt asking you whether you want to search from the beginning won't show and thus the bug can be avoided.
UPDATE: Bug still exists in LibreOffice 3.5.4 Public Release LibreOffice 3.5.4.2 Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18 Exists in LibreOffice Impress's Find Functionality. Problem description (clarification for later): In Impress If you search for a string of text (not from the first slide) and it does NOT find it until the end of the document it will then ask you if you want to search from the start of the presentation. At this prompt the visible slide is replaced with a template, if you do not search from the start, the presentation will be restored as it was, no corruption. If you do search from the start, and it does NOT find the string there as well, the presentation will be replaced with a template. This bug has appeared in all generic (from libreoffice.org) versions that I have used since LibreOffice 3.5.2.2 Build ID: 350m1(Build:202)
For the record, I have started to try to find it out. I was able to reproduce it on master. my current status: the problem should be within the function void Outliner::ProvideNextTextObject (void) line 979 in sd/source/ui/view/Outliner.cxx or below (I mean a function that is called from this one). Since this is the first step where the search or the control spelling are calling this program.
Marking as NEW as it's confirmed, also raising to HIGHEST for importance as this affects too many people and results in data loss. I'm also going to go ahead and put this on the most annoying bugs list. Thanks for posting
<http://wiki.documentfoundation.org/BugReport_Details#Version> <https://wiki.documentfoundation.org/QA-FAQ#How_to_select_correct_Bug_Status> for status NEW [Reproducible] with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit) My Test: 1. download open presentation from <https://wiki.documentfoundation.org/images/c/c3/Finding_out_whats_going_on.odp> > First slide is visible in Normal View 2. <control+f> for find, String "Michaelsen", 'down icon' until end of document > As expected search starts from beginning, no document damages. 3. Redo 'down icon' and 'Restart from Beginning' until you see something looking like a template for an enumeration list with bullets and message "redo from beginning"? 4. Click "No" Expected: search simply stops Actual: Many slides deleted, remaining ones with template contents Same problem with "Find and Replace" Still [Reproducible] with Master " 3.7.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 5af60dc]" (tinderbox: Win-x86@6-fast, pull time 2012-06-14 22:09:53) Also [Reproducible] with "LibreOffice 3.5.5.1 German UI/Locale [Build-ID: c9944f7-48b7ff5-0507789-54a4c8a-8b242a8] on German WIN7 Home Premium (64bit) when I click "no" when the message "Restart from Beginning" appears the second time. Already a problem with 3.5.0 release [Reproducible] with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 2d0998f-090bcba-45cf606]" Win-x86@6 - 2011-12-01_08.37.54) (here also Spell check problem reproducible No Problem: Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [(Build ID: 4f11d0a-adcf6d5-c4bb9bd)]" Windows_2008R8 - 2011-11-18) @Florian Can you help? Bibisecting might help to narrow down appearance of problem some better. @Rodo: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf.
@ jmadero@usa.com: Just a hint, no offence: If you want to nominate a bug as "LibreOffice 3.5 most important bug", i.e. add it to bug 37361, please insert "37361" into the "Blocks" field here (not into the "Depends on" field).
My apologies. I actually asked in the IRC channels and I was told to put in depends on. I checked a couple of the other most annoying bugs and they had it in depends on not in blocks....
Bisected - Slide changed to master document.... ------- ed3f955f538bad00cdac118df31daaacf098f9e1 is the first bad commit commit ed3f955f538bad00cdac118df31daaacf098f9e1 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Fri Dec 9 02:10:51 2011 +0100 source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c commit 2c4537471c932b65e6f72e41881b505c4bbad12c Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> AuthorDate: Tue Nov 29 20:00:55 2011 +0100 Commit: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> CommitDate: Tue Nov 29 20:08:31 2011 +0100 dont mindlessly touch the icc-header file on every build - this little gremlin touches the header file everytime it is run - as icc is very low level, this causes a lot of pointless rebuild - everything from vcl up gets relinked - this slows every empty 'make build' down by more than 40 percent - would really need to check if the file changed before writing, but as we rarely change icc itself, I didnt bother with that :100644 100644 2d9e2bd5eaba2ac0d6a836ff57cd25df29197338 70dfab35f16f30a2c2b97a32e92f6ebff188f4a4 M autogen.log :100644 100644 1b490ce3d8ca956972b88f33f5ef54cba84202a5 8772fd8ad8efeec800cc81214748e6ea8b874a00 M ccache.log :100644 100644 beff12644fd59c04475e990f67ce1ac0e404d83c 7b097ea2be9b801fd57adca3aa8153dc76a7fe44 M commitmsg :100644 100644 836d22c9242e1971da374cbf23c36e1ad8626473 7974485e5b06a7ce5e4063c63dbbf93410dacc43 M dev-install.log :100644 100644 a6ae53922a3b0cc49d14e3a7b9c4dfd87be5c4ef 4d2e0aadc50d19160c2817467e1ab14e37b9a18d M make.log :040000 040000 d77236f0aa011a248abe7d5eded963e3d73c330a eb22b11eefad876794235d47623ff1aa1b291dc5 M opt ----- git bisect start # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # bad: [4c30602f43475389f81b1d981ce8ee9a3410b9d9] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5 git bisect bad 4c30602f43475389f81b1d981ce8ee9a3410b9d9 # good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3 git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5 # good: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42 git bisect good b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4 # good: [216e447cb0a457985f20d4db481fa9c73b0bb775] source-hash-55c5ea43a59e505297fb6fa20b77aaa28f7c67bc git bisect good 216e447cb0a457985f20d4db481fa9c73b0bb775 # bad: [569ab0259fc5fcc3190d9ae9c44e1e28570bc8bd] source-hash-817bf1d41bb07aeb3ed7649d25c2b44ee4acb1fe git bisect bad 569ab0259fc5fcc3190d9ae9c44e1e28570bc8bd # bad: [ed3f955f538bad00cdac118df31daaacf098f9e1] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c git bisect bad ed3f955f538bad00cdac118df31daaacf098f9e1 # good: [db3589a1e013d6095c1ce486b705dd9ee685b308] source-hash-ceb55cd688cebede8cef8408540019fe54528869 git bisect good db3589a1e013d6095c1ce486b705dd9ee685b308 ---- About of the affected LibO: LibO 3.5.0 --> Changed to LibO 3.5 Daily
@Florian: thanks for the bibisect. Just for the futur: the text of the first bad commit is not so imporant. Very important are the last good and the first bad, so in this case: first bad: # bad: [ed3f955f538bad00cdac118df31daaacf098f9e1] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c last good: # good: [db3589a1e013d6095c1ce486b705dd9ee685b308] source-hash-ceb55cd688cebede8cef8408540019fe54528869 so this gives exactly the interval where to look (there are several commit in between) bdfbbb33a491f3ce34375de14ba33436b04 slidesorter1: #i116014# Outliner holds ViewShell as weak_ptr. is my better suspect now. I go ahead with investigation. Info soon. Regards
I have looked at the problem at it looks like spell checking just goes thru all the slides and switches to the master slide view. Which is confusing and look's like the slides were deleted. They were not, we just ended in unexpected view - master slides view. (I think Florian in comment 10 found it too, but I wasn't sure from the formulation)
@Radek: You are absolutely right - where have I had my eyes?! That's still annoying and worrying, but definitively not critical.
Commit bdfbbb33a491f3ce34375de14ba33436b04 slidesorter1: #i116014# Outliner holds ViewShell as weak_ptr. indeed introduces this problem/regression. pjacquod@gmx.ch, do you want to work on it, or should I try fix it?
@Radek: Here some extract of mails in lib-dev list, between me and Thorsten: * goal of this patch and the fact it is the suspect:Answer from Thorsten: well the goal was to decouple live cycles of Outliner and ViewShell - sadly the change mixes a lot of reformatting with that fix. Hard to tell if that is now causing some ripple effects. :/ Later I wrote: ------------------- I locally reverted bdfbbb33a491f3ce34375de14ba33436b04 [..] I can confirm this is the origin of the problem. [..] I also have to say honestly that fixing this patch is beyond my knowledge of LibO code in this area. So if you say OK, I will push my revert to master. This is not the most polite way of fixing it. destroying your correction, but the one that fit to my knowledge there. Or have you time to investigate it and fix it ? Sorry, this sounds not very constructive, but in this period I do not have a lot of free time, so I can not offer more. -------------------- So if you have time / knowledge to do it, it would be the best. Else reverting it would destroy the change mentioned above. But I think for users, this is less problematic than the current status. Your input? Thanks
I have pushed fix to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca644612762921e772ca95d5e8737325d9f343d2 It changes the behavior of spell/find to remember only the starting position. I have also tried hard to find the difference the "Commit bdfbbb33a491f3ce34375de14ba33436b04 slidesorter1: #i116014# Outliner holds ViewShell as weak_ptr." introduced. The change happens deep inside the framework::FrameworkHelper::Instance(rBase)->RequestSynchronousUpdate(); call. It goes down to void DrawViewShell::ReadFrameViewData(FrameView* pView) where master page edit mode is used B+>│311 EditMode eNewEditMode = pView->GetViewShEditMode(mePageKind); │ │312 sal_Bool bNewLayerMode = pView->IsLayerMode(); │ │313 ChangeEditMode(eNewEditMode, bNewLayerMode); It comes from meStandardEditMode, which I wasn't able to find out why it was set differently compared to the time before the bisected commit. So I guess it might be either result of syncing the asynchronous events differently or some change we missed in the problematic commit. After I changed the behavior with my fix, it works as expected, at least I hope so. Hopefully it will not introduce other regressions.
Damages still [Reproducible] with "LibreOffice 3.6.3.1” German UI/ German Locale [Build-ID: f8fce0b] on German WIN7 Home Premium (64bit), but ok with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: 370m0(Build:0)]" {tinderbox: @6, pull time 2012-10-20 14:21:35} on German WIN7 Home Premium (64bit) with separate User Profile for Master Branch
I nominated this one as HardHack on <http://wiki.documentfoundation.org/HardHacks#General>
Looks like it just needs a simple back-port to -3-6 ... :-)
Pushed to -3-6 and closed; looks like this just needed a back-port. Thanks for the report ! :-)