Apache OpenOffice (AOO) Bugzilla – Issue 97566
Open Sina index page hangs OOo
Last modified: 2017-05-20 11:13:17 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
Created attachment 59002 [details] sina-indexpage
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.
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.
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...)
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
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)
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...
seems to be related to issue 98275, will look at this here again once this is fixed
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?
you only need the patch if you are doing this with m39 or higher
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)...
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
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!
Reset assigne to the default "issues@openoffice.apache.org".