Bug 93458 - STATUSBAR: Word and character count don't update after high-word-count document loads
Summary: STATUSBAR: Word and character count don't update after high-word-count docume...
Status: RESOLVED DUPLICATE of bug 93261
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: x86-64 (AMD64) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2015-08-15 20:42 UTC by MartinPC
Modified: 2015-08-16 23:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MartinPC 2015-08-15 20:42:57 UTC
This bug appears to be related to Bug 93261 - Persistently high background CPU usage by soffice.bin with high-word-count Writer document.

In LibreOffice Writer 4, the word and character count displayed in the left of Writer's statusbar would periodically update in real time shortly after a document was loaded, letting the user know that Writer was (apparently) repaginating the document and updating its statistics in background. Sometimes the display update would be paused or interrupted if the user initiated a task (e.g., switching sidebar panels) before the background repagination/statistics updating was complete, but the word and character count would generally display correctly once the task was complete and focus was returned to the document's main frame.

When a high-word-count document is loaded in LibreOffice Writer 5.0.0.5 for Windows (both x86 and x64 editions), the word and character count DO NOT update in real time, and in fact do not appear to update AT ALL until the user has engaged in some foreground activity in the main document frame, e.g., by editing, initiating a spell check, jumping to a bookmark, or jumping to the end of the document. (Significant scrolling seems to trigger a statusbar update but minor scrolling does not.) The word count and character count typically start out by immediately jumping to (very roughly) around 1,700 words and 10,000 characters, and they remain at those initial numbers until the user engages in foreground activity.

Word and character count automatically update within a reasonable time (albeit in a single jump, without intermediate refreshes) for ~14,000-word and ~70,000-word documents. They NEVER update on their own (without user activity) for ~430,000-word, ~570,000-word, and ~720,000-word documents. The bug can be tested on the documents I uploaded for Bug 93261. 

This bug, in itself, is only a minor annoyance -- the user doesn't know when Writer has finished repaginating and updating statistics in background -- but it's a clear regression with respect to LibreOffice 4. That said, I suspect it is connected to another bug I noticed in LibreOffice Writer 5.0.0.5 (Bug 93261 - Persistently high background CPU usage by soffice.bin with high-word-count Writer document). Is it possible the initial background repagination/statistics-updating routine gets stuck in a loop in high-word-count documents? If so, manually updating document statistics (File > Properties > Statistics > Update) doesn't seem to break it.
Comment 1 Jean-Baptiste Faure 2015-08-16 20:06:47 UTC
This bug is a duplicate of bug 93261. Indeed if you apply the workaround i gave for bug 93261 (activate then disable automatic spell checking) the problem disappear (for example try to cut a chunk of text, then paste it again).

Closing as duplicate. Please feel free to reopen if you disagree.

Best regards. JBF

*** This bug has been marked as a duplicate of bug 93261 ***
Comment 2 MartinPC 2015-08-16 23:11:31 UTC
No, the workaround had no effect in 5.0.0.5 x86 or 5.0.0.5 x64 for Windows for this bug, as well.

I'm not sure this is so much a duplicate of bug 93261 as it is an additional symptom of the same underlying bug. I'm not sure how the QA team handles that administratively -- as related, as I initially had it marked, or as a duplicate, as you have marked it -- so I'm not reopening it, as I did with 93261. So long as anyone investigating 93261 is certain to refer to the symptom described in this bug report, it doesn't really matter.