Bug 124603 - Automatic spell check of edited word is made after another word edit starts
Summary: Automatic spell check of edited word is made after another word edit starts
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.7.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.3 inReleaseNo...
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Spell-Checking
  Show dependency treegraph
 
Reported: 2019-04-08 07:59 UTC by Gabriel Masei
Modified: 2022-12-17 22:41 UTC (History)
4 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 Gabriel Masei 2019-04-08 07:59:20 UTC
Steps to reproduce:
1. Open a new/existing document in LibreOffice Writer
2. Check menu option Tools-> Automatic Spell Checking if not already checked
3. Insert some text.
4. Modify a word that initially was spell checked as valid so that it transforms into an invalid word.
5. Move cursor to another word.
6. Modify the word under last cursor position.

Behaviour:
1. After step 4 the word is still considered valid which is a normal behaviour - just wait to finish editing.
2. After step 5 the word from step 4 is still considered valid which is a problem because at this stage the editing of the previous word has finished.
3. After step 6 the previous word is considered invalid (underlined with red). This is correct but too late. This behaviour should manifest after step 5.

Reproduced with:
1. LibreOffice 6.1.4
2. LibreOffice 6.2.2
3. Latest master branch build.

The expected behaviour is that the word should be checked as invalid (if it is the case) after step 5.
Comment 1 Dieter 2019-04-08 19:43:04 UTC
I confirm it with

Version: 6.2.2.2 (x64)
Build-ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

and with

Version: 5.4.7.2 (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: CL
Comment 2 Dieter 2021-03-02 09:23:32 UTC
Tested again with

Version: 7.1.1.2 (x64) / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Actual result:
Word, that I've modified in step 4 is red underlined as soon as I start typing in a different word (Step 6).

Si I'm not sure, if this is a bug or the expected behaviour (and of course it would be an enhancement if a wrong spelling is marked a soon as you move cursor outside tis word).
Comment 3 Gabriel Masei 2021-03-02 13:03:43 UTC
(In reply to Dieter from comment #2)

> Si I'm not sure, if this is a bug or the expected behaviour (and of course
> it would be an enhancement if a wrong spelling is marked a soon as you move
> cursor outside tis word).

Well, I think that it looks more like a bug than the expected behaviour because if you have a misspelled word which is already red underlined and you correct it the underline will disappear automatically at first step that corrects it, even before leaving the word. This looks like an inconsistency in behaviour. I'm not sure if red underlining a word while typing it is the best behaviour but this should happen at least after you leave the word (the word typing is finished). Otherwise the user impression is that the word is correct even if it is not. If the last word typed by the user is misspelled it could be very easily missed. To force a user to type something else just to check that the last word is correct is not a pleasant thing. Why a user should do that if the typing is finished ?
Comment 4 Dieter 2021-03-04 07:24:07 UTC Comment hidden (obsolete)
Comment 5 Dieter 2021-03-04 07:25:21 UTC
I think this is a duplicate of bug 136294. Gabriel, please change it back to NEW with a short reasoning, if you disagree.

*** This bug has been marked as a duplicate of bug 136294 ***
Comment 6 László Németh 2022-10-21 14:45:30 UTC
We can add a more comfortable trigger here, e.g. leaving the edited line.
Comment 7 László Németh 2022-10-21 15:10:51 UTC
Regression from commit 4c91e94e892943ef5e031d65f6f42864233cb4cd
"tdf#92036: sw: fix idle spelling loop".
Comment 8 Commit Notification 2022-10-25 07:16:44 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e3ae86a38d6282db0f54d3545015ed22ee868ae5

tdf#124603 sw: pressing Up/Down triggers pending spell checking

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 László Németh 2022-10-25 07:18:18 UTC
@Gabriel: many thanks for reporting!

@Dieter: thanks for handling the issue!

tdf#124603 sw: pressing Up/Down triggers pending spell checking

Modified text wasn't checked until the next edit operation,
so spelling mistake of the last edited word could go unnoticed.
Leaving the edited line by pressing Up/Down triggers
pending spell checking to fix the problem in most cases.

Regression from commit 4c91e94e892943ef5e031d65f6f42864233cb4cd
"tdf#92036: sw: fix idle spelling loop",

Note: add unit test to tdf#92036, too.
Comment 10 NISZ LibreOffice Team 2022-10-26 07:05:05 UTC
Verified in:
Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 17dfc9a9da009cc23d2222e3fb4e2cef9c97d581
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL threaded
Comment 11 Commit Notification 2022-11-01 19:50:05 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/f9b4ee0859676555bad4f6cc2513baf7135c4bdb

tdf#124603 sw: pressing Up/Down triggers pending spell checking

It will be available in 7.4.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Gabriel Masei 2022-11-03 08:27:52 UTC
Thanks Laszlo for your fix! I've tested it by building the master branch and running locally and it works.

However, I think that the solution is incomplete. The state of the word is changed only if the user presses the up or down keys. This is good but not enough. The issue still manifests if the user performs any other actions (like left/right keys or mouse to change the cursor position or perform a different action, Ctrl + S to save the document, mouse to navigate through menu for choosing an option, ...). I think that the update of the word state should be done after any other action beside editing the word. Maybe we should update the state at "leave the current word" event, if this event is available. Or to update the word after any action from the user. I don't know if the last suggestion is feasible as it could slow the editing but, on the other hand, this will include all cases.
Comment 13 Commit Notification 2022-12-17 13:54:08 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/62f0707f6ff1c0dfca67c8e3d7f6d74d1a43db87

tdf#124603 sw: test only if spelling dictionary is available

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2022-12-17 15:07:16 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/aa9022d932bc46f25978e0d79abc19a9b676f192

tdf#124603 sw: test only if spelling dictionary is available

It will be available in 7.5.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 László Németh 2022-12-17 22:41:45 UTC
(In reply to Gabriel Masei from comment #12)
> Thanks Laszlo for your fix! I've tested it by building the master branch and
> running locally and it works.
> 
> However, I think that the solution is incomplete. The state of the word is
> changed only if the user presses the up or down keys. This is good but not
> enough. The issue still manifests if the user performs any other actions
> (like left/right keys or mouse to change the cursor position or perform a
> different action, Ctrl + S to save the document, mouse to navigate through
> menu for choosing an option, ...). I think that the update of the word state
> should be done after any other action beside editing the word. Maybe we
> should update the state at "leave the current word" event, if this event is
> available. Or to update the word after any action from the user. I don't
> know if the last suggestion is feasible as it could slow the editing but, on
> the other hand, this will include all cases.

@Gabriel: you are right, this solves only the most annoying part of the problem: replacing the mandatory editing with a more comfortable solution. The other part of the problem was filed in Bug 136294. (Likely it's worth to separate the online task (where we don't like the false alarms, which could cause extra network load) from the desktop functionality.) Many thanks for your bug report and feedback!