Created attachment 43458 [details]
HTML page to insert

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
Insert/File...
Then Undo etc.

Created attachment 43466 [details]
Bugdoc without OLE+Graphic objects

Hi Andreas,
You mean open the bug documents with a browser is not necessary?
But there does exist this problem with the page www.sina.com,
and there is no this problem with other web pages for example www.sohu.com.

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?

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. 

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)
Undo
=> the table is not deleted!!!

Created attachment 43485 [details]
Bug document 2 sections 1 table

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?

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). 

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 
bug. 

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 
think. 

The *pUp is in function SwCntntFrm::Cut() in file 
sw/source/core/layout/wsfrm.cxx.

Is it right? 
Ama, can you give me some suggestions?

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
afterwards.
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).

Lijian, you did already some research. Do you like to take over?

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!

->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
SwSectionFrms.

->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.

->lijian:
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:
http://wiki.services.openoffice.org/wiki/Writer_Core_And_Layout#Examples
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
array:
<Section 1>
  <Text A/>
  <Section 2>
    <Text B/>
  </Section 2>
  <Table/>
  <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)>
  <TabFrm/>
  <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>  
<TabFrm/>
<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
paragraph.

->ama:I have sent you a patch for this issue .
Please have a look at it and hope for your suggestions.

.

->ama:I have sent you a new patch. Please review it.

->lijian:
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..

->lijian
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.

->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. 

Created attachment 47830 [details]
new patch for issue 75008

-> 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.

Created attachment 47867 [details]
patch Version II for this issue

->ama:
Please have a look at this patch.
I made it according to SwCntntNode::MakeFrms(..).

Looks promising, I'll test it...

Patch accepted!
Thanks, lijian.

Issues fixed in CWS swqbf105.
ndtbl.cxx

->ama:
Thank you for your continuous help to me!

Ready for QA

Verified in CWS swqbf105

Verified in DEV300_m40 .deb version - Closing - Sophie