This was originally reported by a Fedora user at https://bugzilla.redhat.com/show_bug.cgi?id=2248020 on LO 7.5, but I can reproduce on 7.6 also. Even if Tool->Options->Language Settings->LanguageToolServer is set as disabled in configuration, LO always tries to reach LanguageToolServer at startup. If, for some reason like bad DNS or only local connectivity, LanguageToolServer is not reachable, LO hangs fo several minutes at startup. That doesn't happen if no network connection is available. However, I see two faults here: - if Tool->Options->Language Settings->LanguageToolServer is disabled, LO must not try to resolve LanguageToolServer URL - if DNS/Internet connectivity isn't available, LO must not hang several minutes at startup
I can't repro using Version: 7.6.3.1 (X86_64) / LibreOffice Community Build ID: c4af5b1259bceea6e979e6fe2435dbee7a5a87c2 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded With LanguageTool enabled in Language Settings, I see DNS queries for api.languagetool.org, when starting Writer; but when I disable LanguageTool in settings, and restart LibreOffice, starting Writer does not produce these queries (and other communications). Enabling and restarting the program gives the communications again. Version specific? OS specific? (But I don't see how it would be OS-specific, though.) The communication code is in lingucomponent/source/spellcheck/languagetool/languagetoolimp.cxx. A breakpoint in getCheckerURL there would trigger at every case of getting the respective URL. I recall there were some changes lately related to obtaining list of languages. Possibly they changed the situation. Maybe commit 7fbea38b7aa5335abef55b445df88ee571d18360 ?
From further testing, I can pinpoint exactly how to reproduce the problem. - network connectivity (with or without internet connection) must be up, but DNS must not be reachable (wrong DNS address) - base URL of LanguageToolServer must not be blank (I used https://api.languagetool.org/v2) With these settings, no matter Tool->Options->Language Settings->LanguageToolServer is disabled or not, it seems LO always tries to reach the base URL, but it hangs waiting for DNS reply. With base URL empty that never happen (even with LanguageToolServer enabled). I've reproduced this on Fedora 38 | LO 7.5, Fedora Rwahide | LO 7.6, Debian 12 | LO 7.4.
Reproduced a 20+ second hang with bogus `nameserver 1.1.1.9` in /etc/conf and: Version: 7.6.3.1 (X86_64) / LibreOffice Community Build ID: c4af5b1259bceea6e979e6fe2435dbee7a5a87c2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ... but only if "Enable LanguageTool" is ticked in the Options dialog.
(In reply to Stéphane Guillou (stragu) from comment #3) > Reproduced a 20+ second hang with bogus `nameserver 1.1.1.9` in /etc/conf Should read /etc/resolv.conf (In reply to Mike Kaganski from comment #1) > I recall there were some changes lately related to obtaining list of > languages. Possibly they changed the situation. Maybe commit > 7fbea38b7aa5335abef55b445df88ee571d18360 ? I overlooked that. You're right, no hang in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7d357628d6e8ce3f9e3c3a567ada21f02bce8d42 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded And I checked that it was indeed resolved by Mert's 7fbea38b7aa5335abef55b445df88ee571d18360, which is build commit [e446857446920eaa0e6be5ec1e13197ffdae0643] in the linux-64-24.2 bibisect repo. Thanks Mert and Mike!