Bug 46852 - EDITING: "Change all" fails to change earlier misspellings
Summary: EDITING: "Change all" fails to change earlier misspellings
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Luke Deller
Whiteboard: target:6.0.0
: 91151 (view as bug list)
Depends on:
Blocks: Spell-Checking Writer-UX
  Show dependency treegraph
Reported: 2012-03-01 15:08 UTC by Michael H.
Modified: 2017-07-26 11:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael H. 2012-03-01 15:08:04 UTC
When spellchecking (via F7/menu) is not initiated at the beginning of a document and "Change all" has been clicked for at least one misspelled word, prior instances of all misspelled words to be corrected are not changed when checking is continued after reaching end of document.

Problem reproduction:
1) Create a document with repetitious misspelled words, for example:
catt doge
frogg frogg
frogg catt doge
doge catt
frogg, doge, catt

2) Place cursor on 4th line after second "frogg"

3) Initiate spellchecking with F7

4) Repetitively click on "Correct all" for each misspelling prompt until end of document is reached.

Assuming dog, cat and frog have been chosen to correct the misspelled words accordingly, the text at this point will read as follows:
catt doge
frogg frog
frog cat dog
dog cat
frog, dog, cat

5) Confirm to "Continue check at beginning of document".

Notification appears that "The spellcheck is complete", but the text before "frog" in line 4 has not been changed.

Comment 1 Michael H. 2012-03-01 15:49:04 UTC
Slight correction for 1) my ignorance and 2) top suggested spelling corrections:

1) "doge" is in the English dictionary and is "the chief magistrate in the republics of Venice and Genoa" (amazing what you can serendipitously learn from these bugs!)

2) The spellchecker suggests "tact" for "catt", so the test text now reads

catt dogg
frogg frogg
frogg catt dogg
dogg catt
frog, dogg, catt

catt dogg
frog frog
frog tact dog
dog tact
frog, dog, tact

For some reason the English spell checker begins at the beginning of a line whereas the German spellchecker begins from wherever the cursor is set. 

Oh man, the more I examine this, the buggier it gets!
Comment 2 Urmas 2012-03-09 13:07:55 UTC
This button simply means "replace the word automatically without user intervention", it is not supposed to replace normal search/replace.
Comment 3 Michael H. 2012-03-09 13:56:48 UTC
(In reply to comment #2)
> This button simply means "replace the word automatically without user
> intervention", it is not supposed to replace normal search/replace.

Duh. I know, that is why I reported a bug: The user must intervene after step 5!

Perhaps I wasn't clear enough. The actual bug (unexpected behavior) occurs after Step 5
5) ... "Continue check at beginning of document".

The words at the beginning of the document to be replaced automatically "without user intervention" are not replaced and the notification appears that "The spellcheck is complete". The user must intervene and begin the spell check again!

If you don't think this is a bug, try this in MS Word 2010 or, better yet, do a start a Search & Replace in Writer in the middle of the text/document. Search for "catt", replace with "cat" and select "Replace all". EVERY instance of catt is automatically replaced "without user intervention"! 

The spell checker is expected to function just as Search & Replace would for all entries.

Comment 4 Joel Madero 2014-11-06 20:32:21 UTC
Never confirmed by QA - moving to UNCONFIRMED.
Comment 5 Michael H. 2014-11-07 21:13:50 UTC
(In reply to Joel Madero from comment #4)
> Never confirmed by QA - moving to UNCONFIRMED.

You must be kidding! I just tried this in
(Build ID: 958349dc3b25111dbca392fbc281a05559ef6848)
and I get the same results!

Should I create a new bug for the 4.x release?

Check out "See also", whose status is (still) confirmed.

What else do we need to get this fixed?
Comment 6 Joel Madero 2014-11-07 21:51:04 UTC
It has to be independently confirmed by QA - that is our procedure. Even if QA itself reports a bug, almost always a second QA member confirms the bug.
Comment 7 Joel Madero 2014-11-07 21:57:47 UTC
Instead of bickering I just went ahead and confirmed:

Ubuntu 14.04 x64
LibreOffice 3.3 (inherited from OOo) - updated version as version is oldest not newest

NEW - confirmed
Minor - won't prevent high quality/professional work but can slow you down
Medium - bumped up from low as you get mislead to believing the check happened when it didn't because of the dialog.

needsDevEval - might be an easy hack (honestly not sure). Requesting developer evaluation.

...as you can see, QA does more than just say the bug exists...you're
Comment 8 A (Andy) 2014-11-07 22:38:29 UTC
Thank you very much for your bug report.
I understand your at first glance disappointment but this is probably only a misunderstanding, Joel (as he wrote) only wanted to note that a confirmation from a second user is necessary.  This is a basic and important principle in our QA procedure.  His comment does not mean that this bug is not existing, only that this confirmation is necessary and as I see now Joel has already confirmed this bug in the meantime.  Joel is currently checking older bugs to follow up and verify them (e.g. every New bug must have a second confirmation).
And as Joel I can also confirm your bug.
We also want to thank you very much for your effort to help LO to become better and your patience and we appreciate your effort very much.  If you like you can also join our QA team (this is no formal process, just checking bug reports) and help to check and confirm bugs.  Every help is very much appreciated.
And if you experience any further bug please report it.  This helps LO to become better.

Reproducible with LO, Win 8.1

Steps done (according to Michael's bug report):
1. Create a new document in WRITER

2. Insert the described text:
catt doge
frogg frogg
frogg catt doge
doge catt
frogg, doge, catt"

3. Place the cursor in the fourth line after the second "frogg"

4. Start the spellchecker with F7 or via TOOLS -> SPELLING AND GRAMMAR

5. Press the "Correct All" button until you get the information "Continue checking from the beginning of the document?" (in this case you have to press the button two times for "frogg" and "catt")

6. Now you see in the document the following text:
catt doge
frog frog
frog tact doge
doge tact
frog, doge, tact"

7. Now press the "Yes" button to continue at the beginning of the document

You get the information: "The spell check is complete."
But the document has still the text from step 6.
-> Thus, you see the word "catt" in the third line, which is not yet corrected (-> bug).  If you place now the cursor at the beginning of the document and start again the spellchecker this word will be corrected.  Therefore, the information "The spell check is complete." is not correct.
Comment 9 Michael H. 2014-11-07 23:06:44 UTC
Thanks for the clarification on QA and following up. I'm aware of what QA does. 

What is so alarming was that some of these bugs just seem to sit there (sometimes for years) and the next thing you know, you get a Status Change notice from REOPEN to NEEDINFO followed by UNCONFIRMED within, literally, a minute. This is perplexing and not particularly transparent and certainly doesn't seem (to the layman) to be an acceptable reaction time from QA. Now that I am working in support for a software developing company, I see lots of curious status changes which only internals can understand. (For example, what would anybody "in the real world" think when the status of their bug report goes from CONFIRMED to ASSIGN TO BACKLOG? Doesn't sound too promising, but in my company that means it's scheduled for review by R&D!) Not only that, but we also have ancient bugs or feature request just lingering on and on, year after year, hoping they will just either get resolved by chance or be forgotten by customers that reported them.

Anyway - now I know a little bit better about how things work here at bugzilla and will cool my jets next time ;-)
Comment 10 Gordo 2015-05-20 19:36:40 UTC
*** Bug 91151 has been marked as a duplicate of this bug. ***
Comment 11 Robinson Tryon (qubit) 2015-12-13 11:20:48 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2017-01-03 19:46:22 UTC Comment hidden (obsolete)
Comment 13 Luke Deller 2017-07-13 15:32:58 UTC
I can still reproduce the same behaviour:

Ubuntu 16.04
version (built from git commit e333183d)

I did some investigation in a debugger, and found the problem:

at step 3: the spellcheck starting position (beginning of line 4) is recorded in a bookmark (inside an XTextRange object)

at step 4: the word "frogg" at that position is deleted (before inserting the correction "frog").  This causes the bookmark to be deleted because it is referring to a deleted position.

at step 5: spellcheck from the beginning of the document to the starting position is skipped because the spellcheck starting position has been lost

Notice that if line 4 starts with a correct word, e.g.
"happy frogg frogg"
then the problem does not occur, this is because the starting character of that line is not deleted during the spellcheck corrections.
Comment 14 Commit Notification 2017-07-20 19:28:13 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "master":


tdf#46852 fix spellcheck continue at beginning

It will be available in 6.0.0.

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:

Affected users are encouraged to test the fix and report feedback.