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.
1) Create a document with repetitious misspelled words, for example:
frogg catt doge
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:
frog cat dog
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.
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
frogg catt dogg
frog, dogg, catt
frog tact dog
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!
This button simply means "replace the word automatically without user intervention", it is not supposed to replace normal search/replace.
(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.
Never confirmed by QA - moving to UNCONFIRMED.
(In reply to Joel Madero from comment #4)
> Never confirmed by QA - moving to UNCONFIRMED.
You must be kidding! I just tried this in 184.108.40.206
(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?
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.
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
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 220.127.116.11, Win 8.1
Steps done (according to Michael's bug report):
1. Create a new document in WRITER
2. Insert the described text:
frogg catt doge
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:
frog tact doge
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.
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 ;-)
*** Bug 91151 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (needsDevEval)
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.1.6 or 5.2.3 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I can still reproduce the same behaviour:
version 18.104.22.168.alpha0+ (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.
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.