Description: If spell check is run at the start of the attached test document, the missing space is not found in "took beautiful,his slim". For bigger documents spell check can be run multiple times and eventually those missing spaces are found, but the inconsistency makes it hard to deal with. Steps to Reproduce: 1.open the attached test.odt in a clean LibreOffice Writer 2.run spell check (Tools>Spelling) 3. Actual Results: "DocumentLoader" is found as first result Expected Results: "beautiful,his" should be found as first result Reproducible: Always User Profile Reset: Yes Additional Info: Version: 25.8.0.4 (X86_64) Build ID: 48f00303701489684e67c38c28aff00cd5929e67 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded
Created attachment 202550 [details] test.odt
But the sample doesn't have 'beautiful,his'
It's the first sentence in the sample: "This is a simple test took beautiful,his slim " (sry if I created confusion by using a standard test file and adjusting it ;))
Confirm. After I select all the text and set to English it is working, but not when opening the file Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ro-RO (en_US); UI: en-US Calc: threaded
Sometimes is blue from the first opening. In 10 trying all are blue but with a delay of 2-3 seconds from opening the file.
The way I confirm this bug is: - disable first the Automatic Spell Checking - open the file - enable the Automatic Spell Checking Actual Results: "DocumentLoader" is found as first result Expected Results: "beautiful,his" should be found as first result
Also in Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in Version: 6.1.6.3 Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: nl-NL (nl_NL); Calc: CL fine in Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.2; UI render: GL; Locale: nl-NL (nl_NL); Calc: CL
Bibisect was requested for this bug. I tried to bibisect this bug with several bibisect repos but was unable to do so because it seems that the spell checking doesn't work in bibisect versions of LibreOffice (or at least I was unable to make it work). I was able to test and reproduce the bug with stable and master versions (25.8.1.1 and 26.2.0.0.alpha0+). So I guess this bug is not bibisectable but it would be nice if someone who knows more about bibisecting could provide some information about this.
(In reply to Jussi Suominen from comment #8) > Bibisect was requested for this bug. I tried to bibisect this bug with > several bibisect repos but was unable to do so because it seems that the > spell checking doesn't work in bibisect versions of LibreOffice (or at least > I was unable to make it work). I was able to test and reproduce the bug with > stable and master versions (25.8.1.1 and 26.2.0.0.alpha0+). > > So I guess this bug is not bibisectable but it would be nice if someone who > knows more about bibisecting could provide some information about this. I added a keyword notBibisectable for this bug. Please remove it if you find a way to bibisect this bug.
(In reply to Jussi Suominen from comment #8) > So I guess this bug is not bibisectable but it would be nice if someone who > knows more about bibisecting could provide some information about this. I think you can bibisect by adding an English dictionary to your extensions. https://extensions.libreoffice.org/en/extensions/show/english-dictionaries However, even with version 5.4, the blue line appears after 2-3 seconds. I couldn't reproduce it well.
Saburo, I tbink its not about the delay of 2-3 seconds, its about the case when it is not working at all.
Created attachment 202763 [details] Spelling dialog: "DocumentLoader" found first When I open the Spelling dialog (Tools | Spelling...) the "DocumentLoader" is found first instead of "beautiful,his" ("DocumentLoader" is bold and highlighted with red color). Does this mean that I have reproduced the bug? Or is the bug reproduced when there is now blue line below "beautiful,his"? I'm asking this because I'm not completely sure how I should reproduce this bug. I added an attachment that shows the Spelling dialog.
(In reply to Jussi Suominen from comment #12) > Or is the bug reproduced when there is now blue line below "beautiful,his"? I meant to say "is the bug reproduced when there is no blue line below "beautiful,his".
Bug is reproduced when "beautiful,his" is underlined in blue (after waiting 2 seconds), "DocumentLoader" is underlined in red & Tools > Spellcheck dialog shows "DocumentLoader" as first result (instead of "beauftiful,his". For it was reproducible as described in the first post, but BodganB confirmed it like this: https://bugs.documentfoundation.org/show_bug.cgi?id=168144#c6
bibisected with linux-64-6.0 Preparation steps in my case 1. If you have added an English dictionary extension, remove it. 2. Copy /libreoffice/share/extensions/dict-en/ to /instdir/share/extensions/dict-en/ 3. Download and extract the old library. -libgcrypt 1.8.7 -dbus-glib 0.110-11 *** ac434565aa890f4122397c8c5b710271eb1fd8ee is the first bad commit source 05c704d3bea7f9a7ec51ac28d4d55ba8068f2da5 commit 05c704d3bea7f9a7ec51ac28d4d55ba8068f2da5 author Michael Stahl <mstahl@redhat.com> Fri Oct 06 21:39:24 2017 +0200 sw: fix infinite grammar checking idle loop The grammar checker always wants to be started in DoIdleJobs(), even if all paragraphs are already marked as checked. This is because there is currently no call anywhere of SwRootFrame::SetNeedGrammarCheck(false) to reset the flag and prevent DoIdleJobs from trying to start the grammar checker. This call was already there before but was removed without any justification in commit 9160fe814a46e93da6907e169ce9d58e46fa37f2. This has become an infinite loop in several Junit tests with commit 53da556c600fa82ba84bc7fdce6a594b43f2b097.