Description: In Writer, any document: if I hold the delete key down it only deletes one character, and then the cursor remains stationary, then as a result of holding the key down, the next time I Save or close the document, LibreOffice crashes. Happens consistently. Version 7.6.2.1 (X86_64), Macbook, OS 12.7.1 Steps to Reproduce: 1. hold down delete key 2. save or close document Actual Results: LibreOffice crashes Expected Results: Holding down delete should delete multiple characters. Reproducible: Always User Profile Reset: No Additional Info: (away from my computer)
Not reproduced in: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 2; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Using a DE keyboard. Not using Apple hardware. Can you please share the full details copied from LibreOffice > About? Thank you.
Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Mac OS X 12.7.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Just to clarify this is specifically referencing the del key not the backspace key? If so, I can't help reproduce as I don't have a delete key :( fn + backspace then becomes the delete key but that works fine for me on macOS 13.6.1 and LO 7.6.2.1. However presssing Fn + backspace + cmd + s does open the save dialog.
I'm also unable to reproduce it, I used both the Delete key on my MacBook and the Backspace key on my external keyboard.
Yes, it is the delete key. Thank you so much for trying....
Unable to repro here as well. del key and backspace do not result in a crash for me. I am on Windows however. Marking as WORKSFORME since Stephane, steve, and ToanTran can't repro. tested with: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 50add2043752c7b07beccef9a509bea6c09619f8 CPU threads: 32; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Back to unconfirmed. WFM would be for when you can repro with an older version, but not with a newer one.
@nicholasakers: can you attach a crash log? Or does LibreOffice's "Document Recovery" appear instead of the usual macOS crash dialog? If you only see the "Document Recovery" dialog, can you attach a sample of LibreOffice using the Activity Monitor application? Below are the steps to get a sample of LibreOffice: 1. In the Finder, open the /Applications/Utilities/Activity Monitor application 2. In the Activity Monitor window that opens, double-click on the LibreOffice entry 3. In the dialog that appears, click the Sample button 4. In the window that appears, click the Save button 5. Attach saved file to this bug
Created attachment 192507 [details] Sample of LibreOffice via Activity Monitor after crashing a document by holding down delete key Thank you so much for your time on this.
I updated to version 24.2.0.3 recently, but this problem remains. Also I notice that I was supposed to enter which version was "earliest affected," and that I unfortunately can't recall. It was 7.6 when I reported this bug.
(In reply to nicholasakers from comment #10) > I updated to version 24.2.0.3 recently, but this problem remains. > Also I notice that I was supposed to enter which version was "earliest > affected," and that I unfortunately can't recall. It was 7.6 when I reported > this bug. Thank you for the sample. When I read the sample, the crash is occurring in the following function: 2379 MSWordExportBase::WriteText() (in libmswordlo.dylib) + 555 [0x1aba0e2db] This function is only called when LibreOffice is saving your document as a .docx file. My first guess is that an autosave is occurring while you are pressing and holding the delete key. Does that sound like what you are seeing?
Thanks so much for this. I just tried to crash an ODT file and failed. You must be correct about the MSWord export being a factor! The delete key not deleting more than one character when held down might be a separate problem? I wouldn't know how to address the autosave part of your suggestion. Thanks again.
(In reply to nicholasakers from comment #12) > I just tried to crash an ODT file and failed. You must be correct about the > MSWord export being a factor! > > The delete key not deleting more than one character when held down might be > a separate problem? The problem is that I cannot reproduce this bug on my machine. I have a lengthy Writer document filled with random text and when I open it and press and hold the Delete key, it repeatedly deletes characters as expected. One thing to try is to do a "factory reset" of your LibreOffice preference files. Maybe it won't help, but at least it will eliminate corrupted preference files from the cause. To do a factory reset, select the Help > Restart in Safe Mode menu item and press the "Restart" button that appears. After LibreOffice restarts, a Safe Mode dialog will appear. Check "Reset to factory settings" and also check the 2 checkboxes immediately below just to be safe. Then, press the "Apply Changes and Restart" button. Is there any change after doing a factory reset?
I did a factory reset but unfortunately the delete key issue and the related crashing of MSWord documents seems unchanged. Thank you for your time!
I would try to reproduce it with different macos versions with the same external keyboard. Can you add the document which is crashing as it seems that it is a docx(?)... maybe anonymized? (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission ) This might be a problem of your document? or your template? Let us try that one.
Created attachment 192657 [details] simple text MSWord file I get the same result from a file I save as MSWord format, or from a Word file someone else made. The attached is a simple text file I saved. I can crash this or any other Word file, as far as I can tell, every time. (And holding the delete key down doesn't work no matter the format.)
Thank you for the sample document. Unfortunately, I still cannot reproduce the bug in LibreOffice 24.2.0.3. When I open it on my Silicon MacBook Pro runing macOS Sonoma, pressing and holding the delete key works fine and saving to .docx after that does not crash: Version: 24.2.0.3 (AARCH64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
no repro with Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 10; OS: macOS 14.3.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded using Matias macos bluetooth keyboard (MacBookPro M1Pro) nor Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded using a Logitech cordless "Windows" keyboard. (MacbookPro Retina Mid2014(!)) will check later the next macbookpro. @Nicholas Do you get the message that the file is no ODF or do you have deactivated this reminder message?
I do get the message that the file is not ODF every time I save in a non-odt format.
also no repro with Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Mac OS X 14.3.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded MacBookPro 2018 using the Logitech Windows keyboard Does LibreOffice crash before that message? But I guess the problem is somewhere else as you wrote: "if I hold the delete key down it only deletes one character, and then the cursor remains stationary" I cannot reproduce this at any mac. :-( I believe I do have macos 12.7 system upstairs, I will check later/tomorrow. You are the only one having reported this problem, and you are the only one having a macos12.7 system in this ticket.
If you check the View > Formatting Marks menu item and then press and hold the delete key, do you see any formatting marks added? Probably no formatting are inserted, but since you see a crash when saving, I am wondering if press and holding the delete key is getting converted to a raw hidden character somewhere.
(In reply to Patrick Luby from comment #21) > Probably no formatting are inserted, but since you see a crash when saving, > I am wondering if press and holding the delete key is getting converted to a > raw hidden character somewhere. One more question: which keyboard layout is your Mac set to? If you search for "keyboard layouts" in the System Preference application, what is the first keyboards layout in the "All Input Sources" section that you see? I usually have my Mac set to "U.S." (i.e. QWERTY) or "French" (i.e. AZERTY) so maybe this bug only happens with certain keyboard layouts. If you are using a different keyboard layout, then I can try using the same layout on my machine.
Thank you so much for your time on this! In answer to your questions: -The crash happens after that “non-ODF” message. -I don’t see any formatting marks when holding down delete after selecting View > Formatting Marks. -The 1st keyboard layout that shows up is “ABC – Extended” and the 2nd is “Japanese – Romaji” and those are the only 2.
Created attachment 192701 [details] Crash log in debug build with Japanese - Romaji keyboard layout
(In reply to Patrick Luby from comment #24) > Created attachment 192701 [details] > Crash log in debug build with Japanese - Romaji keyboard layout I can now reproduce this bug with the Japanese - Romaji keyboard layout. With LibreOffice 24.2.0.3, I see the "one character deleted, then nothing for a few seconds". Then, on the next save, LibreOffice crashes. But, in my local debug build, I see the crash while pressing and holding the delete key. So maybe that is progress. I've attached a crash log of my debug build crash in attachment #192701 [details]. Looks like it is in the Writer code but not sure what the code is doing. I am not familiar with the Writer code.
I forgot to mention a workaround: switch your keyboard layout to "ABC - Extended" when editing the document. I couldn't reproduce the crash with that keyboard layout.
I can confirm that this workaround works! Thank you so much. Now that I'm testing keyboard inputs, I can confirm that any Japanese input I use (Romaji, Hiragana, or Katakana) causes the same crash.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef57aeb9ed190e18ebc034b9a45e190aea3f8f1d tdf#158124 KEY_DELETE events do not need an ExtTextInput event It will be available in 24.8.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.
I now think this is a macOS-only bug. It appears that pressing and holding a delete key with a Japanese keyboard layout (and maybe others) gets tangled in my "macOS press and hold" code that forces the "here are all the possible accented characters" popup to appear. I have a fix for this bug and the fix should be in tomorrow's (24 February 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
*** Bug 162473 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/c333985c2948e77ef993f69f40a31dba203ee529 tdf#158124 KEY_DELETE events do not need an ExtTextInput event It will be available in 24.2.7. 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.