Bug 138815 - Faulty spell check after changing focus: Resume - Ignore Once loop, premature "spell check complete" message (GTK)
Summary: Faulty spell check after changing focus: Resume - Ignore Once loop, premature...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
Version:
(earliest affected)
7.2.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.6.0 target:7.5.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Spell-Checking GTK3
  Show dependency treegraph
 
Reported: 2020-12-11 10:03 UTC by quinreis@gmail.com
Modified: 2023-03-31 14:32 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen recording of attempted use of spellchecking (4.13 MB, video/x-matroska)
2022-02-17 06:19 UTC, Luke Kendall
Details
Test file demonstrating the symptoms of this bug. (37.40 KB, application/vnd.oasis.opendocument.text)
2022-10-25 09:41 UTC, Greg's Coffee
Details
The short document that refused to advance on a later "Joscha" (68.61 KB, application/vnd.oasis.opendocument.text)
2023-03-31 08:27 UTC, Luke Kendall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description quinreis@gmail.com 2020-12-11 10:03:32 UTC
When using the manual spell checker, i.e. from Tools --> spelling , or F7, when adding words to the dictionary, the first word adds OK, but after that a window asking me to "resume" comes up, and then another asking to check from the beginning of the document, and finally one saying that the spellcheck is complete, when this is far from the truth. This bug has been present for some time now.
Comment 1 Luke Kendall 2020-12-28 08:00:58 UTC
In recent versions of LibreOffice, spellcheck seems to be almost broken, I agree.
I've found these problems:
After each possible spelling error is found, regardless of what action you take, what happens next is unpredictable:
1) It may state that the spell check is complete
2) It may force you to click Resume
3) It may jump to a random part of the file and begin spellcheck from there
4) It may proceed correctly, to the next closest potential error

I think I've arranged those possibilities in order of most likely to least.

Using spellcheck now takes approximately 100 times as many UI clicks as it used to in Writer, assuming the user has the stubbornness to continue trying to use it.

Something has been badly broken.

I've noticed this on two utterly different documents; a formatted novel of 145,00 words, and a text file of 2.3M words.

Both have moderately large user dictionaries - perhaps that's a factor, if the problem is not immediately reproducible?
Comment 2 Luke Kendall 2020-12-28 08:04:43 UTC
I should add, this behaviour continues in Writer 7.0.3.1.

Also, there may be more error outcomes than I listed above. I just noted an extra one: in the spelling panel a highlighted word has the option to add it to a dictionary, ignore it once, or always, greyed out sometimes, leaving instead only the options of correcting it or closing the spellcheck prematurely.

Basically, spellcheck is broken.  You can't really use it.

I think it should be rated as at least a severe bug.
Comment 3 Buovjaga 2022-02-16 14:51:29 UTC
(In reply to quinreis@gmail.com from comment #0)
> When using the manual spell checker, i.e. from Tools --> spelling , or F7,
> when adding words to the dictionary, the first word adds OK, but after that
> a window asking me to "resume" comes up, and then another asking to check
> from the beginning of the document, and finally one saying that the
> spellcheck is complete, when this is far from the truth. This bug has been
> present for some time now.

I tested this with English (USA) and it added all my nonsense words.

Can you reproduce with 7.3? Please copy and paste here the contents of your Help - About. This allows us to know more about your system.

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.

Arch Linux 64-bit
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: e620fc11709787a7075b281a26c5da3acfc27eb8
CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded Jumbo
Built on 16 February 2022
Comment 4 Luke Kendall 2022-02-17 06:19:59 UTC
Created attachment 178335 [details]
Screen recording of attempted use of spellchecking

Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-GB (en_AU.UTF-8); UI: en-US
Calc: threadedVersion: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-GB (en_AU.UTF-8); UI: en-US

Similar things happen in this version (I just reinstalled it).

See attached video for sample bizarre behaviour that makes spell check quite unreliable in practice - you can have no confidence it finds and lets you address all the spelling mistakes it has found.  Even repeated uses won't guarantee you get to review each one.

I made a little video of an example (series of attempts), with no editing of the document in between: just repeatedly clicking on Tools>Spelling...
Comment 5 Buovjaga 2022-02-17 07:55:16 UTC
Any existing attachment we can use to test it? I know you have uploaded various docs.
Comment 6 Luke Kendall 2022-02-17 11:10:20 UTC
I'm not willing to attach an early draft of my new book to a public site.

I would be willing to provide a copy of it if there was a way to keep it private and out of the bug reporting system.

Hmm, maybe encrypt it in e.g. a zip file and keep the decryption key private somehow?
Comment 7 Greg's Coffee 2022-10-25 09:41:27 UTC
Created attachment 183251 [details]
Test file demonstrating the symptoms of this bug.
Comment 8 Greg's Coffee 2022-10-25 09:43:39 UTC
I've seen this on LO 7.4.2.3. apply the following steps to the file I attached " Test file demonstrating the symptoms of this bug."

1) Exit out of all LO applications.
2) Open speller4.odt attached to this ticket.
3) Place cursor at end of last paragraph
4) Press F7 to start speller.
5) At prompt to continue spelling at beginning of document, click Yes.
6) Speller stops at experiense. Click Ignore All.
7) Speller stops at teachez. Click Ignore All.
8) Speller stops at worc. Click Ignore All.
9) Speller stops at likwuid. Click Ignore All.
10) After one of the steps 6-9, the speller's buttons are all disabled except for Resume.
11) Click Resume, then click Ignore All.
12) Clicking Ignore All causes the speller to ignore all remaining misspelled words.
Comment 9 Buovjaga 2022-10-25 11:17:49 UTC
(In reply to Greg's Coffee from comment #8)
> I've seen this on LO 7.4.2.3. apply the following steps to the file I
> attached " Test file demonstrating the symptoms of this bug."
> 
> 1) Exit out of all LO applications.
> 2) Open speller4.odt attached to this ticket.
> 3) Place cursor at end of last paragraph
> 4) Press F7 to start speller.
> 5) At prompt to continue spelling at beginning of document, click Yes.
> 6) Speller stops at experiense. Click Ignore All.
> 7) Speller stops at teachez. Click Ignore All.
> 8) Speller stops at worc. Click Ignore All.
> 9) Speller stops at likwuid. Click Ignore All.
> 10) After one of the steps 6-9, the speller's buttons are all disabled
> except for Resume.
> 11) Click Resume, then click Ignore All.
> 12) Clicking Ignore All causes the speller to ignore all remaining
> misspelled words.

I don't get the behaviour described in step 10. There is no "Resume" button and nothing is disabled that shouldn't be (disabled are the Ignore buttons, Add to dictionary and Add to autocorrect).

After steps 6-9, there are no misspelled words anymore, so I don't understand step 12.

For testing multiple times, one can edit the ignored words and delete them:
Tools - Options - Language Settings - Writing Aids - User-defined dictionaries: List of Ignored Words

Arch Linux 64-bit
Version: 7.4.2.3 / LibreOffice Community
Build ID: 40(Build:3)
CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
7.4.2-1
Calc: threaded
Comment 10 Rathiga 2023-03-29 07:11:09 UTC
Spelling Check Go To Tools->Spelling.Correct Spell Check In Suggestion.Put the Correct,Change The Correct Spelling in the Wrong English Words.
Same Problem In New Version.
Version: 7.3.7.2 / LibreOffice Community.
Comment 11 Stéphane Guillou (stragu) 2023-03-31 07:38:25 UTC
Some spellcheck fixes made it into version 7.5.2.2.
Could you please retest and report if the issue is still present?
Thank you!
Comment 12 Luke Kendall 2023-03-31 08:22:51 UTC
Tested a very short document with 7.5.2.2

It might be improved.

It ended up looping a bit after about ten spell interactions: At the name "Joscha", I'm presented with top section options of Ignore Once/Ignore All/Add to Dictionary.

Choosing Ignore Once multiple times didn't advance to the next possible error, instead offering a Resume option. Clicking that took me back to the same top three options and didn't advance to next 'error.

After filling out some of this bug report and going back to the spell check, clicking Ignore Once yet again resulted in a "Spellcheck complete" popup.

Closing and reopening the spellcheck let me progress to the end of the document.

Trying on a different, longer document, resulted shortly in the same error: a state in which a flagged word, when you choose "Ignore Once", doesn't advance to the next potential error and instead changes the "Ignore Once" button instead to "Resume".  Clicking that just takes you back to the same word and the "Ignore Once" etc. options.
This time again, taking a minute or two to add to this bug report and then returning focus to Writer, when I then clicked Ignore Once, I got the "Continue checking at beginning of document?" popup.  Choosing No left all buttons except Close greyed out.

Opening the spellcheck again appeared to continue on.  It seemed to work okay, eventually running out of possible errors and saying the spell check was complete.

So I feel it's definitely improved, but at least one of the spellcheck bugs remains.

Version:

Version: 7.5.2.2 (X86_64) / LibreOffice Community
Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2
CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 13 Luke Kendall 2023-03-31 08:27:36 UTC
Created attachment 186355 [details]
The short document that refused to advance on a later "Joscha"

Hope this helps.
Comment 14 Stéphane Guillou (stragu) 2023-03-31 13:08:29 UTC
Thank you, Luke, Yes, just reproduced it with your document, and it looks like "focus" is key in this bug! Here are steps to reproduce the behaviour I was also seeing in bug 153628:

1. open attachment 186355 [details]
2. Click on Check Spelling (or use F7 shortcut)
3. Change focus out of Spelling dialog (in LO or other app), go back to dialog
4. Click on Resume, then Ignore Once.
- Result A: stuck in a Ignore Once - Resume loop.
5. When "Resume" is visible, click on Correct, then Resume, then Correct
- Result B: spellcheck prematurely concludes.

Version: 7.5.2.2 (X86_64) / LibreOffice Community
Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

This is very similar to old bug 48114, but what I can see on Linux only started in LO 7.2. It only affects gtk, not kf5 or gen VCLs. Which explains why buovjaga couldn't see it.

Bibisected in linux-64-7.2 repository to first bad commit df59407b45d65416250a0f05c1c214c81e7c99e5 which points to core commit:

commit c7cfd3323cf80d5953f5c3808c1afd6fec0c674b
author	Caolán McNamara <caolanm@redhat.com>	Mon Apr 05 20:25:42 2021 +0100
committer	Caolán McNamara <caolanm@redhat.com>	Mon Apr 05 22:20:22 2021 +0200
tdf#141499 trigger container_focus_changed for toplevel window focus events
[...]
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113616

Changing the earliest version affected now that we've got a commit. There are obviously other issues listed here, but let's focus on this one.

Caolán and László, copying you both in because of recent work on bug 153628. We now have consistent steps.
Comment 15 Caolán McNamara 2023-03-31 13:59:55 UTC
comment #14 might be addressed by recent https://gerrit.libreoffice.org/c/core/+/149539 to have far less "Activate" calls which was a difference between the gtk version and gen version?
Comment 16 Stéphane Guillou (stragu) 2023-03-31 14:32:47 UTC
(In reply to Caolán McNamara from comment #15)
> comment #14 might be addressed by recent
> https://gerrit.libreoffice.org/c/core/+/149539 to have far less "Activate"
> calls which was a difference between the gtk version and gen version?

Ugh yes, you are right, fixed in master by your work. I forgot those were in 7.5.3, not 7.5.2...
I see it fixed in master build from today.

Let's keep this as the GTK-specific regression, resolved by your commit, so it's visible when dealing with others like bug 48114.

@quinreis, if you are still around, please test a master build and let us know if you still have spellcheck issues: https://dev-builds.libreoffice.org/daily/master/current.html

Thank you all!