Bug 49610 - EDITING: Terminating 'Find' when reached end of document second time brings up "Master View", deletes slides
Summary: EDITING: Terminating 'Find' when reached end of document second time brings ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.5 Daily
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-05-07 21:19 UTC by Kieran Grant
Modified: 2012-11-08 16:31 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of corrupted Presentation Document (157.79 KB, image/png)
2012-05-07 21:19 UTC, Kieran Grant
Details
Screenshot of Impress before choosing an option at search prompt. (248.66 KB, image/png)
2012-05-08 01:39 UTC, Kieran Grant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kieran Grant 2012-05-07 21:19:24 UTC
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)
Comment 1 Kieran Grant 2012-05-08 01:39:26 UTC
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'.
Comment 2 Kieran Grant 2012-05-08 01:40:30 UTC
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.
Comment 3 Kieran Grant 2012-05-08 02:26:11 UTC
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.
Comment 4 Kieran Grant 2012-05-31 15:00:42 UTC
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)
Comment 5 pjacquod 2012-06-17 10:59:57 UTC
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.
Comment 6 Joel Madero 2012-06-17 18:30:44 UTC
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
Comment 7 Rainer Bielefeld Retired 2012-06-17 22:44:46 UTC
<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.
Comment 8 Roman Eisele 2012-06-18 00:35:53 UTC
@ 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).
Comment 9 Joel Madero 2012-06-18 07:08:55 UTC
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....
Comment 10 Florian Reisinger 2012-06-19 10:01:01 UTC
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
Comment 11 pjacquod 2012-06-20 11:32:19 UTC
@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
Comment 12 Radek Doulik 2012-06-22 01:45:28 UTC
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)
Comment 13 Rainer Bielefeld Retired 2012-06-22 03:23:02 UTC
@Radek: 
You are absolutely right - where have I had my eyes?!
That's still annoying and worrying, but definitively not critical.
Comment 14 Radek Doulik 2012-06-22 04:48:22 UTC
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?
Comment 15 pjacquod 2012-06-23 03:03:25 UTC
@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
Comment 16 Radek Doulik 2012-06-28 01:53:43 UTC
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.
Comment 17 Rainer Bielefeld Retired 2012-10-21 13:02:43 UTC
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
Comment 18 Rainer Bielefeld Retired 2012-10-21 13:17:03 UTC
I nominated this one as HardHack on <http://wiki.documentfoundation.org/HardHacks#General>
Comment 19 Michael Meeks 2012-11-08 16:03:49 UTC
Looks like it just needs a simple back-port to -3-6 ... :-)
Comment 20 Michael Meeks 2012-11-08 16:31:45 UTC
Pushed to -3-6 and closed; looks like this just needed a back-port.

Thanks for the report ! :-)