Issue 61557 - Writer frequently hangs
Summary: Writer frequently hangs
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 79346 84776 (view as issue list)
Depends on:
Blocks:
 
Reported: 2006-02-03 09:22 UTC by raindrops
Modified: 2013-08-07 14:38 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description raindrops 2006-02-03 09:22:57 UTC
While working on a 300+ page odt file, I face a problem-- Writer frequently goes
in "wait" mode (it stops responding to user input and shows hourglass all the time).

** There is no "% progress" bar in status bar
** There is no particularly high disk activity at this time.

This "hang" period can last from a few seconds to a few minutes.

But sometimes I ran out of patience and had to close the application using the
conext menu from the task bar.

This particularly happens if I try to draw the elevator bar down soon after
opening the file.

Sampel file available with MRU (private--do not share).
Comment 1 michael.ruess 2006-02-03 09:57:36 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?
Comment 2 raindrops 2006-02-03 13:10:59 UTC
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!
Comment 3 raindrops 2006-02-06 05:20:00 UTC
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.
Comment 4 michael.ruess 2006-02-15 11:58:19 UTC
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 ***
Comment 5 michael.ruess 2006-02-15 12:18:13 UTC
Closing duplicate.
Comment 6 raindrops 2006-03-11 12:52:00 UTC
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!
Comment 7 raindrops 2006-04-11 13:19:24 UTC
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).
Comment 8 kpalagin 2006-11-19 20:50:25 UTC
raindrops,
maybe you could set this issue to "confirmed"?
Comment 9 raindrops 2006-11-20 05:00:05 UTC
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).
Comment 10 jwalter 2006-12-08 20:47:18 UTC
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.
Comment 11 kpalagin 2007-03-27 17:41:05 UTC
raindrops,
do you still experience the problem with 2.2?
Can you provide the file (via, say, www.mytempdir.com)?
Comment 12 raindrops 2007-03-27 18:06:15 UTC
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.
Comment 13 kpalagin 2007-03-27 18:19:56 UTC
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).
Comment 14 raindrops 2007-03-27 20:06:37 UTC
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!



Comment 15 raindrops 2007-03-29 03:44:58 UTC
The manual was sent to you today from my Gmail account.

Thanks.
Comment 16 kpalagin 2007-03-29 04:48:11 UTC
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.
Comment 17 michael.ruess 2007-03-29 09:02:49 UTC
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.
Comment 18 michael.ruess 2007-03-29 09:08:21 UTC
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.
Comment 19 grsingleton 2007-03-29 14:11:01 UTC
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.
Comment 20 raindrops 2007-03-29 15:16:14 UTC
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.
Comment 21 kpalagin 2007-03-29 15:56:24 UTC
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).
Comment 22 kpalagin 2007-04-15 21:00:58 UTC
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).
Comment 23 michael.ruess 2007-07-16 14:28:30 UTC
*** Issue 79346 has been marked as a duplicate of this issue. ***
Comment 24 discoleo 2007-07-16 20:27:16 UTC
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).
Comment 25 mhatheoo 2007-07-21 22:02:22 UTC
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
Comment 26 discoleo 2007-08-26 22:42:06 UTC
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.
Comment 27 discoleo 2007-10-09 20:53:10 UTC
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?
Comment 28 michael.ruess 2008-01-03 11:40:08 UTC
*** Issue 84776 has been marked as a duplicate of this issue. ***
Comment 29 frank.loehmann 2008-01-03 14:35:44 UTC
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.
Comment 30 raindrops 2008-06-14 06:58:02 UTC
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!)
Comment 31 k4os 2009-07-17 23:50:38 UTC
same issue with 160p document with a guessed number of 700 objects and version
300m15