Description: Spelling correction Since several versions, a right click on a word with a spelling error and then the choice "Corregir siempre como" (Always correct as?), deletes the word from the text instead of saving the automatic correction. Windows 10 and 11 Steps to Reproduce: 1. word with a spelling error 2. right click 3. choice "Corregir siempre como" Actual Results: deletes the word from the text Expected Results: saving the automatic correction Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: es Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: YES (not detected by Libre office)
I am unable to reproduce the issue with version Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Are you able to provide an attachment of the word(s) you are trying to correct in your document?
Created attachment 186700 [details] Attached the requested screen shots. I have been systematically reproducing this error, in French and Spanish, for several versions of LO, and therefore cannot use this function.
[Automated Action] NeedInfo-To-Unconfirmed
Please copy and paste here the contents of your Help - About by clicking the copy button. This allows us to know more about your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information. Assuming you don't really have Itanium CPU, so changing that as well.
Created attachment 186860 [details] Screen shot asked
(In reply to dgreusard from comment #5) > Created attachment 186860 [details] > Screen shot asked Thanks, although there is no need to screenshot as you can just click the button to copy. Does it make a difference, if you deactivate Tools - Options - LibreOffice - View - Use Skia for all rendering?
Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: es-ES Calc: threaded I deactivated "Representar todo el programa con Skia", the problem is identical.
Tammy noticed from your screenshots that you are using this for spell checking: https://www.antidote.info/ https://www.antidote.info/en/antidote-9/documentation/user-guide/using-with-your-other-software/windows/libreoffice What if it's a problem caused by it?
Please test with Help > Safe Mode and see if you can still reproduce the issue without the extension.
1. In Safe mode, the behavior is CORRECT. 2. The comment I send to Antidote editor: "I have verified that I am working with up-to-date versions of LIbre Office and Antidote. I confirm that the "Correct as usual" option is a LIbre Office feature, that my LIbre Office interface is in Spanish and that I am working on French content. I have done the suggested test by REMOVING THE CONNECTIX CONNECTOR WITH LIBRE OFFICE: THE BEHAVIOR IS THEN CORRECT. I understand that, if this bug only occurs with the Connectix connector active, all hypotheses are possible: - Antidote or Connectix bug altering the operation of LIbre Office; - LIBRE OFFICE BUG REVEALED BY THE CONNECTION WITH ANTIDOTE. In both cases, the bug must be reproducible by others than me."
I’m one of the developers of the Connectix Connector for LibreOffice at Druide. We have made a very simple LibreOffice plugin without including all our code for connecting Antidote to LibreOffice. This sample just simply try to add no elements to the contextual menu. With this code, we replicate the problem mentioned here. Can someone check if we miss something here that break LibreOffice? I’ll attach EmptyMenu.zip. The main source is in ’src/Context.py’ and to build the extension call ’python scripts/build.py’.
Created attachment 187158 [details] Sample plugin to replicate the misbehavior
(In reply to Jasmin Lapalme from comment #11) > I’m one of the developers of the Connectix Connector for LibreOffice at > Druide. We have made a very simple LibreOffice plugin without including all > our code for connecting Antidote to LibreOffice. > > This sample just simply try to add no elements to the contextual menu. With > this code, we replicate the problem mentioned here. > > Can someone check if we miss something here that break LibreOffice? > > I’ll attach EmptyMenu.zip. The main source is in ’src/Context.py’ and to > build the extension call ’python scripts/build.py’. Have you considered contracting a certified developer to help you troubleshoot it: https://www.libreoffice.org/get-help/professional-support/
We think that the problem is within LibreOffice. The sample code is pretty simple and involves no logic at all. We simply register a `com.sun.star.ui.XContextMenuInterceptor` and return CONTINUE_MODIFIED without any modification to the context menu. In our production extension, we actually modify the menu, with the same result on the 'Always correct as' of the autocorrect functionality. If the problem is indeed in LibreOffice, every extension that registers an interceptor has the potential to break the autocorrect.
When right clicking on a spelling error, and choosing always autocorrect to deletes the word. This occurs since several versions, and even in version 7.6.3. This error is not reproducible when the Language tool is disabled. I thought the problem might be with LT, but having read other comments, can the problem be with LO? Swithing on or off skia does not prevent the error.
Grammalecte has the same issue in bug 157258. I just tested with the LanguageTool extension and get the same problem, also starting in 7.4. Let's mark as a duplicate of that one even though it's a newer report, because a bibisection was done there. Please feel free to comment there. Thank you all! *** This bug has been marked as a duplicate of bug 157258 ***