Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Open Sina index page hangs OOo|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P2||CC:||Armin.Le.Grand, issues, max.odendahl, ooo.redflag, orw, peter.junge|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
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 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!