Issue 75008 - Undo of insertion causes freeze
Summary: Undo of insertion causes freeze
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: OOo 2.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
Depends on:
Blocks: 72764
  Show dependency tree
Reported: 2007-03-01 09:46 UTC by andreas.martens
Modified: 2013-08-07 14:42 UTC (History)
8 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

HTML page to insert (258.74 KB, text/html)
2007-03-01 09:49 UTC, andreas.martens
no flags Details
Bugdoc without OLE+Graphic objects (376.49 KB, text/plain)
2007-03-01 12:29 UTC, andreas.martens
no flags Details
Bug document 2 sections 1 table (7.28 KB, application/vnd.sun.xml.writer)
2007-03-02 12:56 UTC, andreas.martens
no flags Details
new patch for issue 75008 (820 bytes, text/plain)
2007-08-29 03:54 UTC,
no flags Details
patch Version II for this issue (914 bytes, text/plain)
2007-08-30 09:45 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description andreas.martens 2007-03-01 09:46:29 UTC
Open a new Writer document
Open bugdoc with a browser (e.g. with Firefox),
select all
copy to clipboard
insert into Writer document
=> Not all inserted content has been removed by undo
click into this content
=> freeze
Comment 1 andreas.martens 2007-03-01 09:49:39 UTC
Created attachment 43458 [details]
HTML page to insert
Comment 2 andreas.martens 2007-03-01 12:24:50 UTC
It's not necessary to open the bug documents with a browser.
Create a new Writer document withh OOo and import a bug document via
Then Undo etc.
Comment 3 andreas.martens 2007-03-01 12:29:02 UTC
Created attachment 43466 [details]
Bugdoc without OLE+Graphic objects
Comment 4 2007-03-02 02:08:19 UTC
Hi Andreas,
You mean open the bug documents with a browser is not necessary?
But there does exist this problem with the page,
and there is no this problem with other web pages for example

Is this problem related with the Graphic objects or OLE objects in the page?
Through my testing, I found this problem didn't exist in the former version 
m120. But in this version, it does exist and I can't get the reason.

Any ideas from you?
Comment 5 andreas.martens 2007-03-02 11:43:11 UTC
What I'm saying is: yes, we have a problem and I tried to make it reproducible
as easy as possible.
It is not necessary to open the bugdoc with a (foreign) browser and copy&paste
the content to reproduce the problem.
The problem occurs even if you create a new Writer document and insert the
bugdoc via Insert/File..  That's why I created smaller bug documents. Even with
the bug document without OLE objects and without graphics the problem occurs =>
No, it's not a problem of OLE/graphic.
It's a problem with HTML import and undo. I don't know if the root cause is
located in the undo or in the HTML import or both. Maybe the combination of
numbering/table is a problem.
We should try to make the bug dcoument a small as possible. Then we have to
analyse the behavior of the undo actions which are created during the HTML import. 
Comment 6 andreas.martens 2007-03-02 12:54:25 UTC
Ok, I've created another small bug document and it is an .odt!
=> It's not a problem of HTML import, it's an undo bug.

Create a new Writer document
Insert/File... (attachment i75008.odt)
=> the table is not deleted!!!
Comment 7 andreas.martens 2007-03-02 12:56:15 UTC
Created attachment 43485 [details]
Bug document 2 sections 1 table
Comment 8 2007-03-06 02:26:02 UTC
OK,I can reproduce this problem with the document you created.
Maybe this problem is related with the content of the page.
Through analyzing undo of the content, maybe we can find 
something helpful.

So, can you tell me the steps to create this simple document?
Comment 9 andreas.martens 2007-03-06 08:25:44 UTC
Sure, that's easy:
Create new document.
Insert a second paragraph with content "A".
Slecet "A" and insert a section (Insert/Section)
Insert another paragraph behind "A" with content "B"
Insert a table behind "B".
Select "B"
Insert a second section (Insert/Section).
That's it.
The structure of this document regarding our node model is now like this:
<start-node> // content
<text-node> // empty paragraph
<start-node> // section 1
<text-node> // A
<start-node> // section 2
<text-node> // B
<end-node> // section 2
<start-node> // table
<start-node> // cell
<text-node> // table content
<end-node> // cell
<end-node> // table
<text-node> // empty paragraph
<end-node> // section 1
<end-node> // content
AFAIR all works fine, if there is no section 2 in front of the table. So you
could create anther document without this section and try to find the difference
between these two documents.
You could set a break into the destructor of SwTxtFrm, in the bug document the
table content will not be deleted but in the working document (I assume). 
Comment 10 2007-03-15 11:25:36 UTC
After analyzing this bug for some time, I think something wrong happens when 
importing the attachment to the writer. Maybe this can be a reason for this 

In file sw/source/core/docnode/node.cxx, function SwCntntNode::DelFrms()
maybe should not be called when inserting the attachment. The reason why 
SwCntntNode::DelFrms() is called is the content of *pUp wrongly passed, I 

The *pUp is in function SwCntntFrm::Cut() in file 

Is it right? 
Ama, can you give me some suggestions?
Comment 11 andreas.martens 2007-03-20 11:16:54 UTC
I don't think that there is a problem with DelFrms() during the insertion. But
when Undo is called afterwards I missed the DelFrms() for the table. I debugged
a little bit and noticed the following: when the Undo performs it calls the
SwSectionNode::DelFrms() in ndsect.cxx. Normally this should delete all content
of the section including the table which is part of section 1. But somehow the
table has escaped from the section and is not deleted correctly. And now I
noticed that the table background after insertion of my small bug document is
not gray, it's white! That's wrong because the background of section 1 is gray.
If you open the bug document you will see a gray table, if you insert the bug
document into an empty new document, the table is white!
What happens?
In the logical document structure the table is a part of section 1, but in the
layout structure the table frame is outside the section frame! When the section
frame is deleted, the table frame is not deleted which causes the trouble
The bug seems not to be the destruction, its the construction of the table
frame. We have to debug the SwTableNode::MakeFrms(), this function has to create
the SwTabFrm and to insert it at the right position in the layout structure. We
have to compare this situation in the working scenario (opening the bug
document) and the buggy scenario (inserting the bug document).
Comment 12 andreas.martens 2007-05-14 13:13:50 UTC
Lijian, you did already some research. Do you like to take over?
Comment 13 2007-05-15 03:15:24 UTC
ama: I'd love to take over this issue because I did 
do some work on it.
Also hope to get your continuous help.
Thank you!
Comment 14 andreas.martens 2007-07-05 16:48:38 UTC
->lijian: Please have a look at the Sw..Node::MakeFrms(..) methods when the
table is inserted. Because of the nested section situation there must be created
a new SwSectionFrm but this does not take place. Maybe the
SwNode2Layout::NextFrm() isn't sufficient and the SwNode2Layout::UpperFrm(..)
should be called instead. Please check and debug the different MakeFrms()
methods and their use of SwNode2Layout regarding the creation of additional
Comment 15 2007-07-11 09:05:42 UTC
->ama:Are you sure that there is something wrong with MakeFrmsã€NextFrms... ?
I didn't got anything advanced debugging these functions. Maybe it's too 
abstract to debug these layout and node functions.
Also, I found something new:
1.If there is an empty paragraph between section 2 including "B" and the tabel 
including "T", all work fine. And after the empty paragraph deleted, this 
issue appears. 
2.With the issue document i75008.odt, after we insert it to a new document, 
and do undo, there will be some remains. At the moment, the curson is located 
in the top left corner of the document. Then doing nothing except inputing a 
letter from keybord, we will find the remains disappear and all works fine.

With the new finding, can you give me some advices ? Maybe I can step forward 
with this.
Comment 16 andreas.martens 2007-07-11 16:49:32 UTC
You are first finding support my suspicion that MakeFrms does not a good job.
You are second finding, I do not know why the table vanished but I doubt that
this is a healthy situation.
My theory: MakeFrms does not insert the SwTabFrm into the right layout structure
because of the wrong use of SwNode2Layout::NextFrm. NextFrm is not abnle to
create a new SwSectFrm, but this is necessary for the new table node. Did you
have a look at our wiki:
the sixth example is like the bug situation:
1. You have a SwTxtNode and the corresponding SwTxtFrm
2. You Insert two nested section node with paragraphs and table into the nodes
<Section 1>
  <Text A/>
  <Section 2>
    <Text B/>
  </Section 2>
  <Text C/>
</Section 1>
Then you should get the following layout structure:
<SectFrm 1 (Part 1)>
  <TxtFrm A/>
</SectFrm 1(Part 1)>
<SectFrm 2>
  <TxtFrm B/>
</SectFrm 2>  
<SectFrm 1(Part 2)>
  <TxtFrm C/>
</SectFrm 1(Part 2)>  
but you get
<SectFrm 1 (Part 1)>
  <TxtFrm A/>
</SectFrm 1(Part 1)>
<SectFrm 2>
  <TxtFrm B/>
</SectFrm 2>  
<SectFrm 1(Part 2)>
  <TxtFrm C/>
</SectFrm 1(Part 2)>  
The SwTabFrm is not a lower of a SwSectFrm and this is the root cause for the
following crash!
When Undo performs, it deleted as section 1 as well as section 2. The
corresponding SwSectFrms will be deleted and their lower frames. The SwTabFrm is
not a lower of such SwSectFrm and will be not destroyed.
You said, an additional paragraph before the table makes all working. Why?
Because the MakeFrm for this additional paragraph uses SwNode2Layout::UpperFrm
instead of NextFrm.
UpperFrm creates the missed SwSectFrm and inserts the paragraph into the right
layout position. The MakeFrm of the table afterwards uses NextFrm but this works
because now it is not necessary to create a SwSectFrm, this has already be done
and the SwTabFrm will be inserted right after the SwTxtFrm of the newly added
Comment 17 2007-07-19 03:12:47 UTC
->ama:I have sent you a patch for this issue .
Please have a look at it and hope for your suggestions.
Comment 18 cno 2007-07-22 15:35:21 UTC
Comment 19 2007-07-31 10:37:10 UTC
->ama:I have sent you a new patch. Please review it.
Comment 20 andreas.martens 2007-07-31 13:01:40 UTC
Sorry, but your patch would solve the original scenario only.
New Writer document, insert bug document, Undo => Okay with your patch.
But a slightly different scenario and the bug will occur again:
New Writer document
Insert a table (1x1)
Put the cursor into this cell.
Insert/File/bug document
Undo =>
The inner table will not be deleted and cause trouble again..

Comment 21 andreas.martens 2007-07-31 13:10:51 UTC
The bug is caused by two methods:
MakeFrms(..) and FindPrvNxtFrmNode(..)
In the bug case the FindPrvNxtFrmNode(..) delivers the node previous to the new
table but MakeFrms() is not able to insert the table frame into the right
environment. With your patches you try to suppress the delivering of the
previous node and FindPrvNxtFrmNode() delivers the node behind the table node.
Then MakeFrms() would work fine (at least for the bug case). I would prefer to
let FindPrvNxtFrmNode() do its job and to make MakeFrms() more smart. MakeFrms()
should be able to handle these nodes before the table node even if they are in
different sections. The solution is to use UpperFrms() instead of NextFrm() from
the SwNode2Layout class.
Comment 22 2007-08-29 03:53:14 UTC
->ama:Please review this patch made with your suggestions. It seems all the 
problems you put forward before have been solved. :-)
Looking forward to your reply. 
Comment 23 2007-08-29 03:54:27 UTC
Created attachment 47830 [details]
new patch for issue 75008
Comment 24 andreas.martens 2007-08-29 13:47:49 UTC
-> lijian: Two sophisticated problems will be not solved by your patch, I assume.
1. If you insert your file into a header of a document (with at least two pages).
2. If UpperFrm(..) delivers an empty pFrm and bBehind is false, you will crash.
Some words to UpperFrm(..) vs. NextFrm(..)
NextFrm(..) will deliver all SwFrm-occurrences of another SwNode, so you are
able to insert a new SwFrm before or behind this delivered SwFrms. But
NextFrm(..) is not able to handle situations where new layout frames have to be
created because the new and the old SwNode are in different sections.
UpperFrm(..) will always deliver a layout frame for insertion (sometimes self
created frames) and it will deliver a pFrm which can be null e.g. if the new
layout frame is empty.
You should use UpperFrm(..) in each loop iteration to solve 1 and avoid the use
of bBehind and pFrm->Next() for the Paste(..) method to avoid 2.
Please have a look into SwCntntNode::MakeFrms(..) in node.cxx, where
UpperFrm(..) is used accordingly.
Comment 25 2007-08-30 09:45:40 UTC
Created attachment 47867 [details]
patch Version II for this issue
Comment 26 2007-08-30 09:50:49 UTC
Please have a look at this patch.
I made it according to SwCntntNode::MakeFrms(..).
Comment 27 andreas.martens 2007-08-30 09:59:04 UTC
Looks promising, I'll test it...
Comment 28 andreas.martens 2007-08-30 10:43:12 UTC
Patch accepted!
Thanks, lijian.

Issues fixed in CWS swqbf105.
Comment 29 2007-08-31 02:24:08 UTC
Thank you for your continuous help to me!
Comment 30 andreas.martens 2007-10-23 13:31:20 UTC
Ready for QA
Comment 31 eric.savary 2007-11-05 13:22:31 UTC
Verified in CWS swqbf105
Comment 32 2009-01-31 16:02:21 UTC
Verified in DEV300_m40 .deb version - Closing - Sophie