Bug 82091 - Spelling dialog <F7> correction of Calc cells does not remove red wavy underline, but context menu spelling correction does
Summary: Spelling dialog <F7> correction of Calc cells does not remove red wavy underl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: confirmed:4.2.0.4:windows7 confirmed:...
Keywords: bibisected, regression
Depends on:
Blocks: AutoCorrect-Complete Calc-UX
  Show dependency treegraph
 
Reported: 2014-08-03 12:43 UTC by penttila
Modified: 2018-11-21 00:32 UTC (History)
8 users (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 penttila 2014-08-03 12:43:38 UTC
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
Comment 1 Tim Lloyd 2014-08-07 06:09:22 UTC
Confirmed on Fedora 20 4.3.0.3
Windows XP 4.2.0.4
Comment 2 V Stuart Foote 2014-11-01 18:36:14 UTC
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.
Comment 3 V Stuart Foote 2014-11-01 18:44:15 UTC
Also on Linux fc20 LXDE (32-bit) with
Version: 4.2.6.3
Build ID: 4.2.6.3-8.fc20
Comment 4 V Stuart Foote 2014-11-01 18:55:02 UTC
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.
Comment 5 rpr 2015-01-03 00:51:13 UTC
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.
Comment 6 rpr 2015-01-03 00:56:19 UTC
*** Bug 74987 has been marked as a duplicate of this bug. ***
Comment 7 Joel Madero 2015-01-06 17:41:08 UTC
Changing version to reflect oldest version confirmed on (per duplicate).
Comment 8 rpr 2015-08-23 14:58:09 UTC
I still see this issue in LO 5.0.0.5 - tested on Linux Mint 17.2 and Windows XP/7.
Comment 9 Robinson Tryon (qubit) 2015-12-09 18:19:50 UTC Comment hidden (obsolete)
Comment 10 Xisco Faulí 2016-09-12 12:28:48 UTC
Adding keyword 'bibisectRequest'.
Comment 11 rpr 2016-11-25 10:35:42 UTC
I still see this issue in LO 5.3.0Beta1 - tested on MS Windows 10 Pro.
Comment 12 QA Administrators 2017-11-26 17:12:05 UTC Comment hidden (obsolete)
Comment 13 rpr 2017-11-26 21:39:39 UTC
The bug still exists in LO 5.4.3.2 (tested on Ubuntu MATE 16.04).
Comment 14 Buovjaga 2018-07-02 17:05:53 UTC
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.
Comment 15 rpr 2018-07-06 23:11:24 UTC
I still see this bug in LO 6.1 RC1 (tested on MS Windows 10).
Comment 16 János Néhrer 2018-10-08 05:35:17 UTC
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
Comment 17 Aron Budea 2018-10-15 06:27:54 UTC
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
Comment 18 Aron Budea 2018-10-15 06:36:15 UTC
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.
Comment 19 Buovjaga 2018-10-15 18:05:51 UTC
(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.