Bug 79206 - inconsistent spell check underlining
Summary: inconsistent spell check underlining
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Spell-Checking
  Show dependency tree / graph
 
Reported: 2014-05-25 10:48 UTC by mike.hall
Modified: 2024-06-05 05:47 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mike.hall 2014-05-25 10:48:35 UTC 
type a word like abcd
spelling correction underline appears
type a space in the middle
irrespective of whether the first part of the word is spelled correctly, the underline on the second half always disappears 
The underline generally reappears quickly when a further change is made to the file.

Expected result
After splitting a word, both parts should be tested against the dictionary and underlined immediately if not in the dictionary

Same in 4.3.0.0b1
Comment 1 Yousuf Philips (jay) (retired) 2014-05-26 23:34:30 UTC 
yes its true that if you type 'abcd' and then split it as 'a bcd' or 'ab cd', the line appears under the second half, but if you split it as 'abc d', the line appears under the first half. Just to further test it, i typed 'adslfjalskdjsjdfkalsdjkfsjdlkdfj' and then split it, and both parts had underline under them.

Tested in Linux Mint with 4.2.4 abd 4.3 beta 1.
Comment 2 mike.hall 2014-05-27 06:37:02 UTC 
@jay Your comments seem to partly confirm the error, so did not understand why you changed to resolved.

I have now also tested under Mint Qiana with 4.2.3.3 and the issue is exactly the same as in Windows.

With your example of adslfjalskdjsjdfkalsdjkfsjdlkdfj splitting anywhere always leaves the second half without an ubderline until some other edit is done to the file. What's more, if you continually split your example at different points, the second part of the new words are not underlined initially, corrected for previous splits as each new split is made.
Comment 3 Yousuf Philips (jay) (retired) 2014-05-27 08:08:24 UTC 
(In reply to comment #2)
> @jay Your comments seem to partly confirm the error, so did not understand
> why you changed to resolved.
> 
> I have now also tested under Mint Qiana with 4.2.3.3 and the issue is
> exactly the same as in Windows.
> 
> With your example of adslfjalskdjsjdfkalsdjkfsjdlkdfj splitting anywhere
> always leaves the second half without an ubderline until some other edit is
> done to the file. What's more, if you continually split your example at
> different points, the second part of the new words are not underlined
> initially, corrected for previous splits as each new split is made.

No i wasnt confirming the error as 'a' in 'a bcd' and 'ab' in 'ab cd' are words. Well i just retested it again in Linux Mint and i see my instructions were slightly off in that you have to type in 'adslfjalskdjsjdfkalsdjkfsjdlkdfj ' and then split it and that works correctly.

Testing it in Windows XP SP3 with 4.3 beta and the same instructions wont work unless you add another letter after the last space. So if anything, this should be limited to a windows issue. If you disagree that it still happens in Linux, please send in a screencast, if you know how to.
Comment 4 mike.hall 2014-05-28 06:47:54 UTC 
@jay I can't get your example to work 'correctly' on Win or Mint, ie putting the insertion point anywhere in the middle of your example and typing a space without subsequently moving the insertion point leaves the second part without the miss-spleeing underline. 

Agree that Win is worse than Mint in that in Win you can move the insertion point anywhere without the misspelling underline for the second half of a split word reappearing. Inserting any character into the document corrects the previous missing underline. In Mint, you can move the insertion point anywhere within a miss-spelt word without the underline appearing, but moving it outside the word corrects the missing underline. Moving it into the miss-spelt and non-underlined word does not correct the missing underline.

Here's another example (using Mint Qiana on a 32 bit PC):

             type a new line with a following space
queue
             -> no underline - correct

             delete first u
qeue 
             -> no underline until click outside word

             click outside word to get underline, then replace missing u
queue
             -> underline immediately dissapears

This is inconsistent behaviour.

Thus, for me, this is an almost identical bug in both Linux and Win.
Comment 5 Yousuf Philips (jay) (retired) 2014-05-28 23:58:49 UTC 
(In reply to comment #4)
> @jay I can't get your example to work 'correctly' on Win or Mint, ie putting
> the insertion point anywhere in the middle of your example and typing a
> space without subsequently moving the insertion point leaves the second part
> without the miss-spleeing underline. 

'correctly' meant that the underline appear in both words.

> Here's another example (using Mint Qiana on a 32 bit PC):
> 
>              type a new line with a following space
> queue
>              -> no underline - correct
> 
>              delete first u
> qeue 
>              -> no underline until click outside word
> 
>              click outside word to get underline, then replace missing u
> queue
>              -> underline immediately dissapears
> 
> This is inconsistent behaviour.
> 
> Thus, for me, this is an almost identical bug in both Linux and Win.

Yes i can see the inconsistency in behaviour in this example, but this was different from your first instruction to split a word.
Comment 6 mike.hall 2014-05-29 07:03:23 UTC 
@jay Yes, you are right that the second example is different, but it's very likely that the underlying cause is the same in both cases, ie spell check is not being triggered properly. Thus, the two examples are reasonably kept together. I edited the title therefore.

To extend the second example:

                  type queue followed by a space
queue 
                  -> no underline - correct

                  add an extra u
quueue
                  -> no underline until click outside word (linux) or make a change to the document outside the word (Win) - inconsistent since when adding a letter to make a word correct the underline dissapears

I wouldn't be surprised if this one turned out to be a duplicate, but I couldn't find the right bug report. If you can't either, do you think it's time to change the status to 'new'?

Also, I wonder a bit about quoting complete responses, which seem to make reports longer than necessary. Would you consider quoting just a small part, or using something like 'responding to comment n'?
Comment 7 Yousuf Philips (jay) (retired) 2014-05-29 08:41:47 UTC 
Well we both can confirm your latest example but i couldnt confirm your previous one, but you are correct that the spell checkers isnt trigger correctly. I have set it as new now. It would be great if you could do a short screencast of the issue, or else i can do it. :)
Comment 8 mike.hall 2014-05-29 20:17:17 UTC 
(In reply to comment #7)
> It would be great if you could do a
> short screencast of the issue, or else i can do it. :)
Thanks Jay. If you think it's necessary then by all means do a screencast...
Comment 9 Yousuf Philips (jay) (retired) 2014-05-30 04:22:55 UTC 
seems i was able to reproduce your initial bug as i show it in the below screencast < http://youtu.be/l4KWsgOC6Gw >
Comment 10 QA Administrators 2015-06-08 14:41:49 UTC Comment hidden (obsolete)
Comment 11 tommy27 2015-11-22 07:06:17 UTC 
still reproducible under Win8.1 x64 using LibO 5.0.3.
I see the same behaviour in OOo 3.3.0
so issue is inherited from OOo
Comment 12 QA Administrators 2017-01-03 19:35:33 UTC Comment hidden (obsolete)
Comment 13 mike.hall 2017-01-03 19:42:48 UTC 
No change in 5.3.0.1 on Win 64, issue is exactly as set out in the initial descriptions.
Comment 14 Lior Kaplan 2017-10-13 13:41:49 UTC 
Happens in 5.4.1, also happens with RTL text (Hebrew).
Comment 15 QA Administrators 2018-10-14 02:56:44 UTC Comment hidden (obsolete)
Comment 16 mike.hall 2018-10-14 07:43:45 UTC 
No change, bug remains as described - tested with 6.1.2.1 on Linux Mint.
Comment 17 QA Administrators 2019-10-15 02:28:37 UTC Comment hidden (obsolete)
Comment 18 mike.hall 2019-10-15 08:37:06 UTC 
Bug is unchanged in 6.3.2.2 (Win 64)
Comment 19 mike.hall 2019-10-15 08:39:32 UTC 
PS: Suspect bug is inherited from Ooo but not able to test that.
Comment 20 QA Administrators 2023-06-15 03:15:17 UTC Comment hidden (obsolete)
Comment 21 Mike Kaganski 2024-06-05 04:40:00 UTC 
This is not a bug. The spell check deliberately does not underline the word that is currently having the cursor (in any part of it: at the beginning, or in the middle, or at the end), to not annoy the user who types / edits a word. Only after the work is knows to be "done" - i.e., when the cursor is not "attached" to the word - the word may be underlined.

Before the fix to bug 136294, only the following edit, or pressing arrow down (bug 124603), could trigger the re-check, so that the underline would appear. Now, with commit 44e618096511e8f6e0a6344fab19403503c25148, any cursor movement (using arrow keys, PgUp/PgDn, mouse, etc.) would update the underline status. So the discussed scenario will *correctly* work this way:

1. Type adslfjalskdjsjdfkalsdjkfsjdlkdfj
2. Put cursor in the middle
3. Press spacebar
   => The cursor is at the beginning of the second word; the first word is marked, but the second is not (e.g., a user may press Delete key to edit it).
4. Press Left Arrow key
   => The cursor is now not at the second word, so the second word gets underlined, too.