Fixed spelling errors in Calc cells are still marked as faulty with red wavy underline. Steps to reproduce the problem: 1) open a new spreadsheet in Calc 2) select column 'A' 3) in Format → Cells on Character Set tab (?) [the second tab] select Language: English (USA) 4) click OK 5) type in the first three line of column A the following mistyped words: 'tebla' (table), 'cheir' (chair) and 'wintow' (window) 6) as the automatic spell checking is on by default, each mistyped word is underlined with a red wavy line 7) click F7 to activate the spell fixing 8) the words are recognized as English ones and you can 'fix' each mistyped word one-by-one without any problem 9) close the dialogue 10 now each word is fixed properly but they are all underlined by red wavy line, marking them as still faulty ones! 11) you can rerun the spell-fixing process by F7 but it will not find any problem, i.e. the spell checker 'knows' that all problems were already fixed 12) turning off the automatic spell checking removes the red lines only temporary as turning it on again will show the red lines as before Something is not correct in the administration / storage of spelling correctness state! Problem exist on LO 4.2.4.2 LinuxMint 17 Cinnamon and LO 4.2.6.2 WinXP SP2, but works properly with LO 4.1.6.2 WinXP SP2
Confirmed on Fedora 20 4.3.0.3 Windows XP 4.2.0.4
On Windows 7 sp1, 64-bit en-US with Version: 4.2.7.2 Build ID: 933c0aa564ec4f8883ed5732c866db48dca4dac5 Version: 4.3.3.2 Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644 The issue remains as OP with STR. Interesting in that a context menu correction does properly remove the underline, but the F7 Spelling dialog will not. So guess there is a missing bPaintWrong IsPaintWrong or SetPaintWrong test in the mix.
Also on Linux fc20 LXDE (32-bit) with Version: 4.2.6.3 Build ID: 4.2.6.3-8.fc20
Confirmed regression as in OP, and on Windows 7 sp1, 64-bit en-US with Version: 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 present already by the 4.2.0.4 release.
I also see this in LO 4.3.5.2 on both Linux Mint 17.1 and Windows XP/7. Besides what was written in OP I also see the following incorrect behavior: (1) Assume that default language of a spreadsheet is US English and "check spelling as you type" option is enabled. Also assume you have spelling modules for English (US) and German (Germany). (2) In two cells enter correctly spelled text, e.g.: in A1 enter: English text in B1 enter: German text (3) Press F7 to check there are no spelling errors. (4) Change the language of the B1 cell with: Format > Cells > Font > Language: German (Germany) (5) Now in B1 you have text which is misspelled in German language but the text is not underlined with red wavy line. If you press F7 the spell checking finds the spelling errors in B1 but the red wavy line does not appear. To correct this you can edit B1 by just adding and removing a space character and the red wavy underline will appear. After that, if you revert B1 back to US English you will see the problem described in OP.
*** Bug 74987 has been marked as a duplicate of this bug. ***
Changing version to reflect oldest version confirmed on (per duplicate).
I still see this issue in LO 5.0.0.5 - tested on Linux Mint 17.2 and Windows XP/7.
Migrating Whiteboard tags to Keywords: (confirmedRegression -> regression)
Adding keyword 'bibisectRequest'.
I still see this issue in LO 5.3.0Beta1 - tested on MS Windows 10 Pro.
** 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
The bug still exists in LO 5.4.3.2 (tested on Ubuntu MATE 16.04).
I am unable to bibisect this with 43all or the max repos on Ubuntu 14.04. In 4.2 builds and later, it does not show the red underline at any point. In earlier builds it does show them before correction.
I still see this bug in LO 6.1 RC1 (tested on MS Windows 10).
Reproducible in LibO 6.1.2 under Win 8.1 x64 using English spell checker. Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: hu-HU (en_US); Calc: group threaded
Regression introduced in the following range (builds don't start), most likely by one of Kohei Yoshida's commits. Bibisected using repo bibisect-42max. Because showing the suggestion during spell-checking replaced the cell content with the suggested word, and removed the red underline, I clicked away to a different cell (which reset the word + underline), and accepted the correction afterwards. https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=3003613389f1d2d2fd79812c8ccc6c111b64962e..a6a06e0f23a6aced46b9f0b899cd81bd8d2f2dec
Btw, I don't think any of these commits got into LO 4.1, so in that case perhaps bug 74987 is a different issue.
(In reply to Aron Budea from comment #18) > Btw, I don't think any of these commits got into LO 4.1, so in that case > perhaps bug 74987 is a different issue. Seems so and was WFM on master.
Dear penttila, 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
Reproducible in LibreOffice Calc 6.3.3.2 (running on Ubuntu 18.04).
The problem seems to be fixed in LO 7.1.3.2 (Tested in the Flatpak version on Linux Mint 20.1 Cinnamon) Some notes: 1) when the 'spellcheck fixing dialogue' pops up, the red wavy line on the misspelled word is immediately removed although the spelling problem is not fixed yet. It would be more logical to remove it only after a 'fix' is provided by the user. 2) when a suggested fix is just 'ignored' by the user - in my opinion - it means that the original spelling is said to be OK by the user but the red wavy line remains under the problematic word. I don't know what should be the correct behaviour in this case!
(In reply to penttila from comment #22) > The problem seems to be fixed in LO 7.1.3.2 (Tested in the Flatpak version > on Linux Mint 20.1 Cinnamon) > > Some notes: > > 1) when the 'spellcheck fixing dialogue' pops up, the red wavy line on the > misspelled word is immediately removed although the spelling problem is not > fixed yet. It would be more logical to remove it only after a 'fix' is > provided by the user. > > 2) when a suggested fix is just 'ignored' by the user - in my opinion - it > means that the original spelling is said to be OK by the user but the red > wavy line remains under the problematic word. I don't know what should be > the correct behaviour in this case! Thanks for testing. You could file two separate reports for the things you noted.