Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Writer frequently hangs | ||
---|---|---|---|
Product: | Writer | Reporter: | raindrops <na1000> |
Component: | ui | Assignee: | AOO issues mailing list <issues> |
Status: | CONFIRMED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | frank.loehmann, issues, joerg-walter, kpalagin, mh.hh, pagalmes.lists, stefan.baltzer |
Version: | OOo 2.0.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
raindrops
2006-02-03 09:22:57 UTC
This may be the "idle formatting" process which works in the background. Every document needs "page formatting" especially when they are as complex as the mentioned one. this can be started manually by "Tools.Update.Page formatting" and will give you a progress. When this has finished, working with the document will be easier (when the process runs in background, it will need of course much more time than starting it manually). Are you satisfied with this explanation of this "technical limitation" of working with complex documents? Actually, not at all! I have several reasons for this (and all these are straight from the popular book "GUI bloopers" if I may say so!) 1. The background process completely takes over, and does not let me do anything. It is anything but "background". 2. In many cases, this happens very soon after I open a saved document, when there is hardly any change. So why does Writer think that it should maintain the document? 3. If the task is (say) more than 10 seconds, then it should bve treated as a long duration task, and Writer should show a progress bar for it. How will the user know when this task is going to be over? And how long can I wait before forcing a close (and losing the work done)?? 4. When an author is writing a long document, he would be more often interested in reaching the end of the document; where he is working currently. But this is precisely where Writer fails to respond: When I drag the elevator downwards (to jump to a page towards the end), Writer hangs. In fact, just before going into meditation, Writer shows a partial page in a very dark background, as if the page is about to be rendered, but then Writer goes into hang mode. I think at least THIS thing may not be a background issue at all. In fact, assume that the Writer is still loading the later document, and the user wants to jump to that part. Even in that case, Writer should respond correctly, and not panic. If it can't do that, then Writer should load the document dfully and only then show it. Thanks! Raindrops ->MRU, I did some further investigation, and now I have clinching evidences that this IS abnormal behavior: 1. Open another type of file first. (say Impress or Calc), and do some little work. (Note that we deliberately selected the FIRST file that is NOT used by writer.) Also, open the online help file (press F1). Now open the odt file I sent you and then try clicking on the vertical bar (or drag the elevator). When Writer gets busy (shows hourglass), try to switch to the first file. Logically, we should be able to work on this file while Writer is busy with the odt file. But you will not be able to switch, or work on the first file. Even the online help file cannot be used at this point. Conclusion-- The entire OOo becomes "busy"; not just the Writer. Also, this is not a "normal" background task; or a limitation that users can be content with. 2. OOo goes into meditation only when I click on the vertical scrollbar (or drag the elevator downwards). But till that VERY moment, Writer looks ready to receive user input. That means these two actions are confirmed triggers for the problem. On the other hand, if I use the Navigator to go to the bottom of the document, Writer does not hang at all. I can start work immediately and keep working without any hangs from Writer. After this, I can drag the elevator or click in the vertical scrollbar. Writer does NOT go into maintenance mode at all! Well, WHY doesn't Writer sense that maintenance is required in THIS case? The document's state is EXACTLY THE SAME: The only difference is that I used some other mechanism to go downwards. So why does Writer misbehave ONLY IF my first action is to go down in the document with those two mechanisms? 3. Just to eliminate the possibility of any left-over maintenance work in the document, I updated the document using the "Tools > Update > Update all" command; and then saved the document.After that, there should not be any maintenance work left. Even then Writer launches this so-called "maintenance task" when I reopen the document. BTW, when the entire updating takes just a couple of seconds, just what is that Writer does for so long? Certainly worth investigating with a debug version. We now have an issue with a public document which should also cover the problem here. The performance lack is insisted by the very large tables in the documents. I will close this one in favor for issue 62028 (I put you on cc-list there). *** This issue has been marked as a duplicate of 62028 *** Closing duplicate. Although this issue is closed, I will continue adding new observations here: I just found that I had JRE 1.5.0.2 and JRE 1.5.0.6 in the same PC. (Recently I added SDK also (for Eclipse). Would that make any difference, I wonder! Reporting for 2.0.2 now. I have modified the original document (cleaned it up drastically; like removing floating frames). Then I added a few pages (now stands at 320 pages). But within a few minutes of opening, the new document invariably hangs. The Writer shows an hourglass for mouse pointer. Even after a few hours there is no change in this. But if I make some changes immediately after opening and then quickly save the file, it does not hang. A few minutes of idle time is enough to trigger the problem. I can share the latest file (privately). raindrops, maybe you could set this issue to "confirmed"? IMHO the initiator should not confirm the issue; someone else should crosscheck the issue independently and confirm. Otherwise we will end up with many spurious issues that are confirmed by the initiator! BTW this problem has worsened; and often the Writer hangs even before I can do a stroke of work. I have raised another issue (issue 70268), which OD has taken over. Work has already started on that issue (and a few related issues which were split from it). I experienced a similar problem with a 300+ pages doc with 2.0.4 on Win XP HE. The most striking fact is that the page counter in the status bar starts counting approx. up to twice the actual number of pages. After some seconds the app calms downs and works normal again thenceforward. raindrops, do you still experience the problem with 2.2? Can you provide the file (via, say, www.mytempdir.com)? Yes. I am using RC4 of 2.2 now, and still it has the same problem. The latest version of the document is available with MRU. Could you please take it from him? Thanks! It has grown to 355 pages; and now I cannot even open it, as Writer hangs immediately. I am unable to do any work on it! Writer's algorithms has several defects as described in Issue 70268. Unfortunately, work on that issue has stopped, and resources are diverted elsewhere. raindrops, as I do not work for Sun I think it would be easier for you to just send the file or link to it to kpalagin@openoffice. . Alternatively, if that file makes OO hung on another machine you should just confirm the issue (and increase the priority because it is loop). OK I will send the file to you by tomorrow through my Gmail account. (It reports some temporary problems today). It hangs on two different machines. Besides, MRU and OD have both confirmed this on their machines, but no one has confirmed this issue so far. See Issue 70268 also. BTW this page does not offer any controls to confirm this issue, but it allows me to resolve the issue directly! PAH! The manual was sent to you today from my Gmail account. Thanks. Confirming with 2.2m14 on WinXP. D-click supplied file, wait 1 minute - soffice.bin starts eating CPU and never stops. Upping priority. raindrops, I suggest providing a link to the file so that devs can access the file at any time. You can host the file at www.mytempdir.com for example or just attach the file to issue (I have seen 9MB attachments, so 4MB should be OK). Dear developers, this issue is yet another example where our strength (claimed by Marketing) in working with long docuents fails. Please consider targeting this issue for 2.2.1. Resetting Prio to 3. This issue is originally not about Writer being stuck in an infinite Loop. For raindrops document causing a loop, I have filed issue 74763 some time ago. This issue is about to enhance the formatting behavior of Writer. It needs some time for updating the document view/structure while working on it without showing any info about it to the user. MRU->AMA: I think, we should really somehow enhance Writers behavior on formatting during working on large documents. A good sample is the document from issue 60340. Sometimes the user will be stopped on working for many seconds while Writer updates the documents layout. I cannot confirm the claim. The user guide is indexed from a single file of around 6Mb containing between 481 and 523 pages. I will grant that automatic saving does seem to slow input down but not significantly. This may not be related to size, but how images and other elements are anchored, and how many algorithms are activated as a result. (e.g. in my case there are many tables, and a lot of images are anchored to rows. This causes a lot of activity.) In other words, larger documents may not necessarily misbehave if they have a simpler structure. mru, if this issue is not about loop then Summary should reflect this so that laymean like me does not cause confusion. grsingleton, I am sure Writer is capable of handling long documents. The probem is - it can't handle some of them. The bigger problem is that our customers negatively affected (to the point of not being able to use the document). raindrops, I think you just have to get users of your application to vote for both of your issues. Create a page explaining the situation, asking to vote and explaining how to register and vote (no need to leave additional comments). Judging by desc18 this is dup of http://www.openoffice.org/issues/show_bug.cgi?id=54640 (but I will leave this decision to QAE or devs). *** Issue 79346 has been marked as a duplicate of this issue. *** I have filed a similar bug: see issue 79346 (closed as duplicate of this). To quote that bug: > I am trying to read and correct the OpenFormula document > (see OASIS site) http://www.oasis-open.org/committees/documents.php?wg_abbrev=office-formula > Unfortunately, Writer *repaginates* every 20-30s, and the number of pages > fluctuates continuously between 300-500 pages, rendering any work impossible. > Please note, that even after more than 2 hours, Writer still repaginates > (I think it repaginates, because the number of pages continues to change). > So, after some 20-30 s, it jumps to a different page > (total number of pages displayed changes, too). > This makes working on larger documents impossible. This is a serious bug, because I, and presumably many others, am/are NOT able to work with the OASIS documents (OpenDocument - Formula Public Documents). So I hope this gets urgently fixed. The following automatic error report: rftxvc was generated while opening one of those documents (see above mentioned bug for the details). question please: isn't it right that this issue is related to version 2.2.1 also? and isn't it right, that this is in regard to ODF-file-format also? so isn't it a regression for the release of 2.3? Martin As a side note, I tested the official documents posted on the OASIS-site (see http://www.oasis-open.org/committees/documents.php?wg_abbrev=office-formula) with OOo 2.3dev OOG680-m2 and the problem persists: - loading the document takes a long time (much longer then in previous versions of OOo) - when scrolling towards the last third of the document, OOo will continuously repaginate the document and thereby jump from one page to a completely different page, rendering any work impossible I have also experienced: *crash* + *data loss* + triggering document recovery crash + *CORRUPTING* initial document after document recovery (P1 !!!) after pasting a simple image into a 6 page document containing a table: see issue 81033 for details. The loop-problem seems corrected in OOo dev m231, see issue 81033 for further comments. Therefore, the document mentioned herein will be probably opened without major problems anymore. However, as stated later in this issue: > This issue is about to enhance the formatting behavior of Writer. Shouldn't the summary be changed accordingly? *** Issue 84776 has been marked as a duplicate of this issue. *** The OASIS document works for me after updating to OOo 2.3.1 (aka SO 8 PU9). My problem with a spec still remains the same (scrolling frequently hangs): http://specs.openoffice.org/appwide/security/Electronic_Signatures_and_Security.sxw I think we should check other bug docs to verify this issue and decide which issues are fixed with OOo 2.3.1. There are so many issues split from this one that I am confused as to where to add my new observations! Well, the 300m14 seemed to have resolved the issue. But the latest 300m17 has the problem, and it is worse than any earlier versions! The document hangs every few seconds. (This is not the same issue as "indefinitely hanging" problem I reported separately. The document DOES become available after about a minute. So there is a duty cycle: a few seconds of editing, followed by 1-2 minutes of waiting!) same issue with 160p document with a guessed number of 700 objects and version 300m15 |