Created attachment 103972 [details] Core dump from the crash On OSX 10.9.4 / LO 4.3.0.4 release: Steps to reproduce: 1. Create a new Writer document 2. Insert a comment 3. Within the comment, start typing any Japanese text with the 'Kotoeri' - 'Hiragana' input method. For instance, 'aaaaaaaaaaaaaaaaa' (which will produce the text 'ああああああああああああああ') 4. Without confirming the input conversion (i.e. without pressing 'Return'), select a new font from the font dropdown 5. Either a crash will occur at this point (see attached backtrace), or a hang when the next Japanese text is input This appears to be specific to comments - I have not observed the same crash occuring in the body of the document
Additional note: When the above results in a hang rather than a crash (i.e. when the font selection is initially successful rather than crashing immediately), I notice that the text that is being entered is deselected, indicating that the input conversion has been aborted When doing the same thing in the main document text, the text remains selected, and the conversion is not aborted, so the font can be changed in mid entry. This should also be possible in a comment * I've just spotted a coincidental but probably(?) unrelated issue; in the main document, when changing the font while a Japanese input conversion is open, the font is correctly applied to the whole text of the input, but *only when the next character is entered*. Raised separately as bug 82116
Hi Matthew, Thanks for this new bug and crash report. Adding the Mac QA team to confirm.
Hi, to reproduce I'd need to know how to "start typing any Japanese text with the 'Kotoeri' - 'Hiragana' input method". Sorry I've not once in my life used those method - whatever they may be.
(In reply to comment #3) > Hi, to reproduce I'd need to know how to "start typing any Japanese text > with the 'Kotoeri' - 'Hiragana' input method". Sorry I've not once in my > life used those method - whatever they may be. In OSX 10.9 it's like this: (earlier OSX may be slightly different) 1. Open "System Preferences" from the Apple menu 2. Select "Keyboard" 3. Select the "Input Sources" tab at the top of "Keyboard" 4. Click on the "+" button at the bottom left to add a new input source 5. Select "Japanese" on the left, then "Kotoeri" on the right and click on "Add" 6. Back in the "Keyboard" - "Input Sources" tab, make sure that at least "Input modes:" "Hiragana" is enabled in the Kotoeri options (this should be enabled by default) 7. At the bottom of "Keyboard" - "Input Sources", make sure that "Show Input menu in menu bar" is enabled (again, probably enabled by default) To test: 1. Open a Writer document 2. With the writer document focused, open the input menu, which is an icon somewhere on the right side of the system menu bar, and select the option that looks like "あ Hiragana" 3. Type some "aaa"s, which should appear as "あああ" At this point, you should be pre-editing some Japanese. What would normally happen next is that you either press "Space" to convert the phonetic text you've entered (a popup will appear at the cursor with some options), and/or "Return" to accept the text as it is currently. While in the pre-editing mode, the text at the cursor that the input method is handling is underlined, and in the case of LO also appears as selected text in the document Reproducing the bug involves changing the font while the pre-editing mode is open within a comment, before pressing "Return" to confirm/exit.
Confirmed:OSX:4.3.0.4 -> NEW Thanks Matthew for making this idiot proof description (Comment 4, and then back to initial Description). I was able to reproduce the crash. Attaching a video (not too much too see - instead of mouse pointer, I was seeing the psycho pizza of death, after changing the font to "Bauhaus 93"). Interestingly the crash did not occur, when I changed the font to Times New Roman. Crash log not attached, since we have that from Matthew already.
Created attachment 104410 [details] video
It looks like the originally attached backtrace actually related to the now fixed bug 82260 - the traces seem identical. The issue that Foss successfully reproduced is however still present in git (which I have now built), and under a development build gives a rather different backtrace, which I will attach.
Created attachment 104421 [details] Updated backtrace
Occurs all the way back to 3.3.0 (and still in 4.4.0.2) Setting Version to "Inherited from OOo"
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
Any better with recent LO version? (last one is 5.1.4)
With master sources updated yesterday, I could reproduce the hang.
Created attachment 125911 [details] bt with symbols
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
Had to try a couple times, but managed to reproduce this when changing the font to Bauhaus 93 as mentioned in comment #5 This is a niche data loss bug, so raising importance to critical
I don't have a Mac anymore, could someone give it a try with last LO version 6.2.4 ?
Still occurs as of builds two months ago (no nightly builds available for download) Version: 6.3.0.0.alpha0+ Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Matthew/eisa01: would you be interested in building LO code so we may: - an up-to-date stacktrace - add some patches to try to debug (I can submit patches to add some traces and you'd retrieve them so your build would show even more info) ? Of course, it may help for other MacOs bugs. If yes, you can take a look at https://wiki.documentfoundation.org/Development/BuildingOnMac You must know that few LO devs use Macs and since it concerns CJK bugs, I think (I may be wrong) there's even less chance to have some update here. Alex: do you still have some pb to build? If yes, perhaps we may ping Tor?
Still occuring 1. Create a new comment 2. Type aaa (in Hiragana) 3. Select the text aaa 4. Change font 5. Click after the aaa text 4. Press enter -> Crash Version: 6.4.3.5 Build ID: 4db9852e73d9e9d662fc8a2783bace79addf1805 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Dear Matthew Francis, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have posted a patch that fixes this bug: https://gerrit.libreoffice.org/c/core/+/143619 The patch needs still needs to be reviewed and tested before it appears in a nightly build. Are there any people who have a macOS LibreOffice build that can test the patch? Overall, the patch commits any uncommitted text when one or more of the following events occur: - The focused window changes - A menu item is selected - Text is entered with the Command key pressed
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/60d2dd11a73bf7a1269896f15b1ec7c98507571e Related: tdf#82115 Fix crash when handling input method events It will be available in 7.5.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9ee57f36e26373ee7144d076c93c3462c4fc7110 tdf#82115 Commit uncommitted text when a popup menu is opened It will be available in 7.5.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/b542092be87b889b58ae95a2d1838a4ee520cabf tdf#82115 Commit uncommitted text when a popup menu is opened It will be available in 7.4.4. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/9e79476499718fa802cd725cdd4aaa4b3b1f9d29 Related: tdf#82115 Fix crash when handling input method events It will be available in 7.4.4. 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.
Please ignore the code change messages. Those changes fix a separate crash that I found while testing the fix for this bug: https://gerrit.libreoffice.org/c/core/+/143619 That patch in the above link still needs to be reviewed and tested before it appears in a nightly build so if anyone with review privileges can review the patch, it would be very much appreciated.
Resetting status back to "resolved". The following patch *did* get committed last night so it should be available in the next nightly build.
Change input methods, such as the OSX built-in Japanese input method, is one potential fix mentioned by a user in Comment 4 https://pougame.co/