I'm running OpenOffice 4.2.0.4 on Windows 7 (using the US-International Keyboard). When I run a Spelling and Grammar check and come across a misspelled word, the "Correct All" button does not automatically correct every instance of the word throughout the document. Instead, it functions exactly the same as the "Correct" [Correct This Time Only] button, correcting only the single highlighted instance. Because this bug can hugely increase the time and attention required of users to run Spelling and Grammar checks, and increases the likelihood of inconsistent corrections, it qualifies as MAJOR. Related bugs, to be filed separately: * The "Always Correct" button below the "Correct All" button in the actual Spelling and Grammar module is undocumented and appears to be entirely nonfunctional (i.e., it doesn't appear to do anything at all). * The error correction buttons in the actual Spelling and Grammar module are labeled "Correct", "Correct All", and "Always Correct". The help module and online documentation (still?) refer to them as "Change" and "Change All". (As noted earlier, the "Always Correct" / "Always Change" button seems to be entirely undocumented.) An unrelated bug, to be filed separately: * After a new word is added to a dictionary, other instances of that word in the Spelling and Grammar checker's text selection are still flagged as unknown. The dictionaries are apparently not checked again until the checker has moved on to a new text selection. (Example: The checker's selection includes the sequence "Raggmopp! Raggmopp! Raggmopp!" The first Raggmopp is flagged as unknown and the user adds it to a dictionary. The second Raggmopp is flagged, despite having been added to the dictionary. Once the checker has moved on to a different text selection, however, further instances of Raggmopp are no longer flagged.)
Hi. "Related bugs, to be filed separately" : You are perfectly right, just do it... ;-) First bug : - It seems to me that the "correct [once]" or "correct all" process the current occurence or all occurences WITHIN the selection. If you want to process your whole text, select it before running the Spelling and Grammar check. Second bug : - I agree, undocumented and inoperant Third bug : - I reproduce/agree Fourth bug : - I don't reproduce (LibO 4.2.1.1 on Win7). It works for me.
In the first line of my bug report I meant to write that I am running LibreOffice 4.2.0.4, not OpenOffice. Sorry. (Is there an edit button somewhere?) Dominique: Unfortunately, only two of the four bug reports I submitted seem to have actually posted: this one and the one about the "Always Correct" button being undocumented and nonfunctional/inoperative. I guess I'll try to resubmit the others. What with the addition of an apparently new, undocumented, inoperative "Always Correct" button, it's hard to know how the spellcheck module's designers intend the "Correct All" button to work. The documentation says only that it "replaces all occurrences of the unknown word with the current suggestion." If I were limiting my spellcheck to text I've selected in the document, I would expect it to replace all occurrences within the selection. If I were running a spellcheck without having selected text -- i.e., from the cursor's position in the document forward, toward the end of the document (and optionally resuming from the beginning of the document after being prompted) -- I would expect it to correct every instance it found until the spellcheck is terminated. Ignoring for the moment what the "Always Correct" button might be intended to do differently from the "Correct All" button, having to select text for the "Correct All" button to function is not practical, since some corrections (e.g., deleting stray paragraph breaks) require you to switch focus from the spellchecker back to the document. If you had selected the entire document, you would have to exit the spellchecker, make your correction, and then select forward to the end of the document before launching the spellchecker again ... each time you make a manual correction to the document. Moreover, you apparently can't even launch the spellchecker if you text selection includes an index field. (The document I'm working on right now has a table of contents; if I select the entire document, the spellchecker won't launch.) Having to manually select text for the "Correct All" button to work requires extra thinking and work and defeats the purpose of automation. As I said, it's not practical. Finally, if the "Correct All" button isn't supposed to work unless you've selected text, why isn't it grayed out or simply not displayed when no text has been selected?
Hello Peter, *, I cannot confirm your first part of this bug with LO Version: 4.1.5.3 Build-ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 nor with Version: 4.2.3.3 Build ID: 6c3586f855673fa6a1576797f575b31ac6fa0ba3 (parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel), both with Germanophone help- as well as langpack ... :( All wrongly written words were corrected, when I press the "Correct All" button. What I did: 1. Created a new Writer document 2. Inserted "Dies ist eni Test." (should be "Dies ist ein Test.") 3. Marked the sentence and C&P it a couple of times 4. Set the cursor at the beginning of the document 5. Pressed <F7> 6. Clicked on "Correct All" All wrongly written "eni" were changed to the correctly written "ein" ... ;) To your related bug: In my Germanophone version it is called "AutoKorrektur", and if you press the Help button, you will find a page to its function (though not directly. You have to click on "Menü" – "Extras" – "Rechtschreibung" and on the link "Dialog Rechtschreibprüfung" to get to the text <quote> AutoKorrektur Überträgt die aktuelle Kombination aus beanstandetem Wort und korrigiertem Wort in die Ersetzungstabelle der Funktion AutoKorrektur. </quote> , roughly translated: <quote> AutoCorrect Transfers the current combination of the questioned word and the corrected word to the replacement table of the function AutoCorrect. </quote> ). You can test it, if you go to "Tools – AutoCorrect Options..." and search for a word, that is missing there. Then write this word in a Writer document, start the spellchecking dialog and press "Always Correct". The word should be in the "AutoCorrect Options" then. The only bug there might be, that the AutoCorrect function is meant and therefor this button is labeled incorrectly ... :( Please open separate bugs instead of one with several problems/bugs in it in the future. Otherwise someone else might close them as invalid ... ;) And as you have found this bug in Apache OpenOffice, you should report it to their bugzilla ... ;) Sorry for the inconvenience Thomas.
@Peter CM please put the other bug reports links under the "See also" field moreover I strongly suggest to upgrade to LibO 4.2.3.3 or wait one more week for 4.2.4.2 (see release schedule here https://wiki.documentfoundation.org/ReleasePlan/4.2 ) since the 4.2.0 version you use was a very early release with lot of bugs (more than 400 bugs have been fixed meanwhile).
please give an update of the bug status with current LibO 4.2.6.3 or 4.3.2.2 releases.
I just updated to 4.3.2.2 but won't be able to do any testing until this weekend at the earliest.
Sorry for the additional delay. Due to a wind storm, there were major power and Internet outages in my area over the weekend. "Correct all" seems to work for the most common pattern of multiple occurrences of the same misspelled word -- specifically, where the misspellings are separated by other words. For example, when you click "Correct all" for the first instance of "ocurence" in the following sentence: “Correct all” should correct each ocurence and every ocurence of the highlighted misspelling. the sentence is appropriately corrected to: “Correct all” should correct each occurrence and every occurrence of the highlighted misspelling. HOWEVER, there is a problem with how the Spelling Checker finds and selects subsequent misspellings to correct, and in some cases in how it applies the correction -- specifically, where the misspellings are not separated by other words. (This is not merely a hypothetical possibility; I encountered it in real life while spell-checking a manuscript.) I designed a couple of "extreme-case" blocks of misspelled text to showcase the problem: When I used "Correct all" to correct "Ocurence" to occurrence" in the following paragraph: I said “ocurence, ocurence, ocurence.” I got: I said “occurrence, occurrence, ocurence.” [last "ocurence" not corrected] When I used "Correct all" for each misspelled word in the following block of five identical one-sentence paragraphs: Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. I got: The the quick quick brwobrown brown fox fox jmjumps jumps over over the the lazy lazy dgodog dog. [three selection/correction failures] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [period incorrectly added after first "dog"] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. Dog. [period incorrectly added after first "dog" and second "dog" incorrectly capitalized] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [period incorrectly added after first "dog"] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [period incorrectly added after first "dog"] So, as I said, there seems to be a problem with how the Spelling Checker finds and selects subsequent misspellings to correct. I'm not a coder, so I can't even guess why it added periods (full stops) to the first "dog"s, or why it capitalized one of them, unless AutoSpellcheck somehow got activated despite being reported as de-activated everywhere in the interface (toolbar icon, Spell Checker Options, Tools > Options > Language Settings > Writing Aids). NOTES: AutoSpellcheck was "turned off" during all of these tests. However, I noticed that "teh" was nonetheless automatically corrected to "the" as I typed. I ran these tests in both 4.2.0.4 (the version I was running when I initially submitted the bug) and in 4.3.2.2 (the current release version, which I am running now). I'm pretty sure the results were exactly the same; the same general problem was definitely present in both versions.
(In reply to Peter CM from comment #7) > > > When I used "Correct all" to correct "Ocurence" to occurrence" in the > following paragraph: > > I said “ocurence, ocurence, ocurence.” > > I got: > > I said “occurrence, occurrence, ocurence.” [last "ocurence" not corrected] I confirm bug under Win7x64 using LibO 4.3.2.2 status NEW
This is not related to English only, we had reports of the same thing happening in any language that has a grammar checker installed in LO.
- Tested Text - ocurence, ocurence, ocurence. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. - Result Text from Master - occurrence, occurrence, ocurence. The the quick quick brwobrown brown fox fox jmjumps jumps over over tehthe the lazy lazy dgodog dog. The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. ---------------------- So a number of problems are occurring during this process. 1) the spellcheck is not fully selecting the word when it wants to replace it, sometimes not selecting a single character. e.g. it has the 'n' in 'brwon' selected and the resulting replacement is 'brwobrown'. 2) When it partially selects a word to replace, if you press any button (e.g. Ignore Once) it will ignore this an act like i pressed 'Correct' or 'Correct All' 3) When i click 'Correct All', it doesnt correct all throughout the document, it does it only within the same line, so if i did 'Correct All' for 'Teh' to 'The' and then clicked the close button, it wouldnt correct all through the document. Version: 5.1.0.0.alpha1+ Build ID: 78a11f79d8eb5cd1d2b18c288852dec7e3d57a21 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-10_05:59:19 Locale: en-US (en_US.UTF-8)
(In reply to Yousuf (Jay) Philips from comment #10) > - Tested Text - > > ocurence, ocurence, ocurence. > > Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz > layz dgo dgo. > > Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz > layz dgo dgo. > > Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz > layz dgo dgo. > > Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz > layz dgo dgo. > > Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz > layz dgo dgo. > > - Result Text from Master - > > occurrence, occurrence, ocurence. > > The the quick quick brwobrown brown fox fox jmjumps jumps over over tehthe > the lazy lazy dgodog dog. > > The the quick quick brown brown fox fox jumps jumps over over the the lazy > lazy dog. dog. > > The the quick quick brown brown fox fox jumps jumps over over the the lazy > lazy dog. dog. > > The the quick quick brown brown fox fox jumps jumps over over the the lazy > lazy dog. dog. > > The the quick quick brown brown fox fox jumps jumps over over the the lazy > lazy dog. dog. > > ---------------------- > > So a number of problems are occurring during this process. > > 1) the spellcheck is not fully selecting the word when it wants to replace > it, sometimes not selecting a single character. e.g. it has the 'n' in > 'brwon' selected and the resulting replacement is 'brwobrown'. > > 2) When it partially selects a word to replace, if you press any button > (e.g. Ignore Once) it will ignore this an act like i pressed 'Correct' or > 'Correct All' > > 3) When i click 'Correct All', it doesnt correct all throughout the > document, it does it only within the same line, so if i did 'Correct All' > for 'Teh' to 'The' and then clicked the close button, it wouldnt correct all > through the document. > > Version: 5.1.0.0.alpha1+ > Build ID: 78a11f79d8eb5cd1d2b18c288852dec7e3d57a21 > TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: > 2015-08-10_05:59:19 > Locale: en-US (en_US.UTF-8) I'm pleased users are still keeping tabs on this bug and hope that it will get assigned. There's clearly a fundamental flaw in the spell checker's selection and replacement algorithm. Thanks, Jay.
(In reply to MartinPC from comment #11) > I'm pleased users are still keeping tabs on this bug and hope that it will > get assigned. There's clearly a fundamental flaw in the spell checker's > selection and replacement algorithm. Thanks, Jay. The flaw seems to be limited to the 'Correct All' button. :D @Qubit: Does this deserve a higher priority as the spelling dialog is a highly used feature of writer and the correct all button would likely be the most clicked button. The only workaround is to use 'Correct' and that would waste quite a bit of time is you've misspelled a word multiple times, but would be the only way to guarantee that it fixed everything occurrence. Bug 46852 is related in some extent, though it talks about correct all not fixing issues when the cursor is not placed at the beginning of the document.
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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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! Warm Regards, QA Team MassPing-UntouchedBug-20170103
I am confirming the bug in LibreOffice 5.2.4.2 (x64) in Windows 7 Pro x64 SP1 and reporting that it dates back to LibreOffice 3.3.4 (x86), with a minor change in correction behavior along the way. I also note a fairly significant, possibly unrelated performance regression. In 5.2.4.2 (x64), I again spell-checked the following block of five identical one-sentence paragraphs. The grammar check was disabled and I ran the spell check both limited to the pre-selected block and on the entire test document (which contained a few other paragraphs): Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. I clicked the "Correct All" button for each flagged misspelling and got the following result on both the selected-block and entire-document spell-check runs: The the quick quick brwobrown brown fox fox jmjumps jumps over over tehthe the lazy lazy dgodog dog. [Four selection/correction failures.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [Correct except that a period was incorrectly appended to the first "dog" instead of just to the second "dog" at the end of the sentence.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [Ditto.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [Ditto.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog. dog. [Ditto.] The spell-check dialog took almost 10 seconds to populate each time it was started. (I have a Core i5 520M laptop with 8GB of RAM and a mechanical HDD. I was using an empty Standard dictionary, an empty IgnoreAllList, a tiny custom BugTesting dictionary, the not-very-big Technical dictionary, and the standard en-UK and en-US dictionaries.) While waiting to populate, the spell-check dialog was sometimes flagged as "not responding" and sometimes it wasn't. The first lowercase "teh" was not highlighted in red, but "the" was properly proposed as a correction. The first lowercase "dgo" was also not highlighted in red, but "dog" was properly proposed as a correction. The second "dgo" was improperly highlighted as "dgo.", incorrectly including the period. After the "Correct All" button was clicked to replace all instances of the second "dgo"/"dgo."(the last word in the first sentence) with the proposed "dog", the spell-check dialog always hung for almost 30 seconds before completing or continuing with the spell check (in both selected-block and entire-document runs). During the hang, the "dgo." in the first sentence remained uncorrected on-screen and the spell-check windows was *not* flagged as "not responding". When the "Correct All" button was clicked a second time during the hang (as you might do if you weren't sure that the first click had registered), the spell-check dialog *was* flagged as "not responding". In 3.3.4 (x86), my "Change All" runs yielded the following: The the quick quick brwobrown brown fox fox jmjumps jumps over over tehthe the lazy lazy dgodog dog [The same four selection/correction failures as in 5.2.4.2, no incorrect period at the end of the second-to-last word in the sentence (the first "dog"), but also no period at the end of the sentence (the second "dog").] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog dog [Correct except for the missing period at the end of the sentence.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog dog [Ditto.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog dog [Ditto.] The the quick quick brown brown fox fox jumps jumps over over the the lazy lazy dog dog [Ditto.] There were no loading delays or processing hangs in 3.3.4's spell-check dialog. The first lowercase "teh" was not highlighted in red, but "the" was properly proposed as a change. The first lowercase "dgo" was also not highlighted in red, but "dog" was properly proposed as a change. The second "dgo" was improperly highlighted as "dgo.", with the period. So far, except for the hangs this is the same behavior as in 5.2.4.2. However, whereas 5.2.4.2 put a period at the end of both "dog"s, 3.3.4 omitted the period from all changed sentences entirely. So, I've been able to provide more details with this round of tests, and while new developments or regressions seem to account for the hangs (which I don't recall from my previous tests in 4.x), it looks like the core problem was inherited from 3.3. I'm guessing that at some point someone tried to fix the missing-period problem but didn't get it quite right. By the way, best regards to Yousuf "Jay" Philips for having pushed for action on some of the bugs I've reported, and to contributors from Red Hat (Caolán McNamara?) for fixing a couple of them. I'm very grateful. Happy new year to all.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Peter CM, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I tested my previous horribly typo- and duplicate-ridden sample text, to wit: ocurence, ocurence, ocurence. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. Teh the quikc quikc brwon brwon fxo fxo jmps jmps ovre ovre teh teh layz layz dgo dgo. in LibreOffice Writer 7.0.4.2 (x64) for Windows, both unselected and as a selected block. The "Correct All" bug *seems* to be fully resolved. I don't know who fixed it, or when, but I'm grateful! Related But Not Technically On Topic: I see that the "[Add to] AutoCorrect [table]" button is still labeled "Always Correct" in the English-language interface, which is not entirely accurate and can be confusing to users who don't proactively research how it works. (It only "always corrects" manually typed text, and only when AutoCorrect is turned on. It doesn't correct pasted text that is subsequently spellchecked.) I think something like "→AutoCorrect" would be better.
Changing Status according to QA convention. WORKSFORME The problem used to be reproducible, but it is not anymore with the latest version of LibreOffice. Unlike FIXED, exact fix commit is not known.
Thanks. In the past few years, I haven't been using LO nearly as much as I once did — due to lack of projects, not because it's bad or because I'm using something else! — and I've completely lost what small familiarity I had with the bug-reporting system. I appreciate the reminder.