Issue 97566 - Open Sina index page hangs OOo
Summary: Open Sina index page hangs OOo
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: DEV300m37
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 84292
  Show dependency tree
 
Reported: 2008-12-25 03:20 UTC by amy2008
Modified: 2017-05-20 11:13 UTC (History)
6 users (show)

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


Attachments
sina-indexpage (305.46 KB, application/x-tar)
2008-12-25 03:21 UTC, amy2008
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description amy2008 2008-12-25 03:20:04 UTC
Can reproduce it with DEV300m37 on WinXP and Fedora

How to reproduce it
1 Decompress attached files to your desktop, you can see '新浪首页.htm' and 
  '新浪首页_files' 
2 Open a new document (Writer,Clac etc.)
3 File - Open, open '新浪首页.htm' on your desktop

Result
OOo hangs

Expectation
OOo can open the file 

Regards
Li Meiying
Comment 1 amy2008 2008-12-25 03:21:19 UTC
Created attachment 59002 [details]
sina-indexpage
Comment 2 michael.ruess 2009-01-07 14:20:28 UTC
MRU->OD: could you please have a look with a debugger whether this is a layout
loop or a problem in the HTML filter? Thanks a lot!
I also saw the loop in DEV300m37.
Comment 3 Oliver-Rainer Wittmann 2009-01-08 11:16:03 UTC
First investigation reveals:
- A lot of assertions during HTML import from /svx/source/svdraw/
- A lot of assertions from layout process
- Assertion from PostIt-Manager that it will loop forever.
- A lot of assertions from PostIt-Manager.
--> loop

OD->MOD: Can you have a look, please.
Comment 4 Oliver-Rainer Wittmann 2009-01-08 11:31:47 UTC
Opening of the HTML file works with the following workaround:
- new text document
- insert note
- hide notes (Menu View - Notes)
- insert the HTML file into the created document (Menu Insert - File...)
Comment 5 max.odendahl 2009-01-08 11:32:26 UTC
mod->od: yes, will have a look

btw, the postit manager warns about a loop, but does not actually loop, as it
drops out after 50 layout iterations
Comment 6 Oliver-Rainer Wittmann 2009-01-08 11:33:30 UTC
On the above workaround I forgot to mentioned that after the insertion of the
HTML file the notes can be made visible (Menu View - Notes)
Comment 7 max.odendahl 2009-01-09 15:48:08 UTC
mod->od: could you look into it again?

I don't even get to the postit layout manager here(MacOS X), it seems to stop
earlier waiting forever for a semaphore

Postit Manager should not loop, even though there is the warning, see
http://svn.services.openoffice.org/opengrok/xref/DEV300_m37/sw/source/ui/docvw/PostItMgr.cxx#1027

btw, it seems it is also trying to start spellchecking and then telling it
cannot find language "default", so beside all these assertions, sth. else seems
to go wrong

Happy to look into it again if you have any hints...
Comment 8 max.odendahl 2009-01-20 14:35:30 UTC
seems to be related to issue 98275, will look at this here again once this is fixed
Comment 9 max.odendahl 2009-01-23 11:46:58 UTC
mod->od: ok, first we need this patch

Index: source/ui/docvw/postit.cxx
===================================================================
--- source/ui/docvw/postit.cxx	(revision 266734)
+++ source/ui/docvw/postit.cxx	(working copy)
@@ -808,10 +808,9 @@
 
 	CheckMetaText();
 	SetPopup();
-	SetPostItText();
 	SetLanguage(GetLanguage());
 	View()->StartSpeller();
+	SetPostItText();

This will get rid of the layout manager assertions and warning loops...

mod->od,aw: when I now try to open the file, the issue seems to be the overlays,
it is running forever inside OverlayManager::ImpDrawMembers, where it always
finds a next one to draw. I stopped now after around one hour. I don't know if
it just takes so long (which would be also not acceptable I guess), or if there
is a real loop, meaning the last overlay points not to NULL but to the first one
again. As not showing notes and then inserting the file works, I would think the
second. Maybe AW has any idea how a situation like this could happen?
Comment 10 max.odendahl 2009-01-23 11:48:51 UTC
you only need the patch if you are doing this with m39 or higher
Comment 11 Armin Le Grand 2009-01-23 11:55:39 UTC
AW: Just a guess, but it may depend on what You do in Your
OverlayObject::drawGeometry and/or OverlayObject::createBaseRange
implementations. It is neither allowed to lead to ANY Invalidate() call (which
would lead to a paint loop) nor allowed to add/remove other OverlayObjects
(which would change the list the current OverlayObject repaint is based on)...
Comment 12 max.odendahl 2009-01-23 12:07:42 UTC
mod->aw: as far as I can tell, I am doing it correctly, only Outputdevice.Draw*
calls. 

Would you have a look:

http://svn.services.openoffice.org/opengrok/xref/DEV300_m37/sw/source/ui/docvw/postit.cxx

It is 

SwPostItShadow::drawGeometry
SwPostItAnkor::drawGeometry
Comment 13 Armin Le Grand 2009-01-23 12:35:28 UTC
AW->mod: Those methods are absolutely correct, so my mentioned reasons cannot
apply. I can give You dispensation on these :-) Sadly, i have no direct other
reason to offer; You will have to check the chain in
OverlayManager::mpOverlayObjectStart to OverlayManager::mpOverlayObjectEnd of
double-linked OverlayObjects. This list is maintained from OverlayManager::add
and OverlayManager::remove which have to be seen as atomic operations. Maybe
fastest check is to quickly write a test method and to assert on loop (coloring
algo, e.g.). HTH!
Comment 14 Marcus 2017-05-20 11:13:17 UTC
Reset assigne to the default "issues@openoffice.apache.org".