Created attachment 74685 [details] LO on the left - Mozilla on the right Problem description: ==================== LO/Writer does not show some text in the editor, even if present in the file. File is an HTML, text belongs to a long paragraph <P>. There are only some breaks <BR>. Really scary. LO/Writer 3.6 was working fine on the same file. In my use case this is a serious issue, and I will fallback to previous LO version. I cannot attach the file I was working on, because copyrighted. Steps to reproduce: =================== 1. Try to create a very long paragraph <P> with plenty of breaks (problem appears after 1000 lines in HTML file saved by LO (maximum line at 80 characters?) Current behavior: ================= No more text. Please check the attachment with LO on the left and Mozilla on the right. Please also check the attachment with the HTML code. Expected behavior: ================== Showing correct text. Operating System: Windows XP Version: 4.0.0.3 release Last worked in: 3.6.5.2 release
Created attachment 74686 [details] HTML extract
Created attachment 74687 [details] HTML extract - working
Actually, LO 3.6.5.2 gets stuck in infinite loop (or something similar). I also attach a test file to reproduce.
Created attachment 74692 [details] Test long paragraph
Steps to reproduce: =================== Just open the test file with LO/Writer.
Same problem (missing text) on LO 3.5.4.2 under Linux.
the problem is that Writer paragraphs have a max size of 64k. hmm... clearly LO shouldn't crash or loop when at or close to the limit. for the more general problem of the 64k paragraph limit see bug 30668. the general problem would be a lot of effort to fix and is currently not being worked on because there are lower hanging fruit elsewhere.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=549c0f785d4b6d4bc1b39b22827d77d66f48430a fdo#60732: SwTxtNode: limit to less than STRING_LEN chars The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d47218d79a2440e71efb66b2224063801ba6623b fdo#60732: make callers of SwTxtNode::InsertText more robust: The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b6d45f26ea5bcc848737921b59a16253eb1d8587 fdo#60732: check max size in SwTxtNode::ReplaceText The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e49d87d92a3f1aeeeda547f1a7e710dcd4fee95 fdo#60732: check max size in SwTxtNode::ReplaceTextOnly The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
so i've fixed the easy part of this: for some reason some of the idle tasks loop or crash when operating on a paragraph that has the max capacity of characters in it. rather than figuring out why this happens, i've decided it's better to slightly lower the limit so the paragraph cannot fill up the String completely; this at least prevents the obvious problem that a SwPosition cannot refer to the index after the last character in a full String. also, it no longer loops. furthermore i've added some checks to various operations in subsequent commits to maintain the limit on editing operations. so this should fix the "regression" aspect of your report. this is of course just one aspect of the problem, but the _real_ problem of the 64k limit on paragraph content is already tracked in bug 30668, and so the non-fixed aspects of this bug are a duplicate of that. hence i'll declare this bug here fixed.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6972ce2673c9a1ad0de1a09c4ecf4fd036c59826&h=libreoffice-3-6 fdo#60732: SwTxtNode: limit to less than STRING_LEN chars It will be available in LibreOffice 3.6.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=81e283a8e5039ab7cd4d3f2ff9c520577a97ac03&h=libreoffice-4-0 fdo#60732: SwTxtNode: limit to less than STRING_LEN chars It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bfd73a7c7b8c7e87f1edafa9d8ec257bfae26a0f&h=libreoffice-4-0 fdo#60732: make callers of SwTxtNode::InsertText more robust: It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for your fix. I am wondering... what happens if you open a file with a paragraph bigger than the limit? Is it going to be truncated (so loosing text), or is it just a display limit?
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b08fe833186a04f9aef698a540d3a7493ac4519&h=libreoffice-4-0 fdo#60732: check max size in SwTxtNode::ReplaceText It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=47211c07ebb9e56caeb57e4d879da6e67a1119df&h=libreoffice-4-0 fdo#60732: check max size in SwTxtNode::ReplaceTextOnly It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #12) > this at least > prevents the obvious problem that a SwPosition cannot refer to > the index after the last character in a full String. oops, this is actually not the case, SwPosition did not have this problem, it seems i wasn't able to count when i wrote that. > also, > it no longer loops. that benefit still exists however :)
(In reply to comment #16) > I am wondering... what happens if you open a file with a paragraph bigger > than the limit? Is it going to be truncated (so loosing text), or is it just > a display limit? it's going to be truncated. also, it would be probably better to rename this bug to something that is actually fixed; again for the not-fixed truncation problem see the other bug.
*** Bug 55125 has been marked as a duplicate of this bug. ***