Bug 82293 - macOS: Cancelling CJK input method pre-editing and then undoing breaks the input method (see comment #10)
Summary: macOS: Cancelling CJK input method pre-editing and then undoing breaks the in...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: macOS-UI-polish CJK
  Show dependency treegraph
 
Reported: 2014-08-07 11:59 UTC by Matthew Francis
Modified: 2022-09-04 02:00 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace from crash under 4.4 git (58.82 KB, text/plain)
2014-08-07 11:59 UTC, Matthew Francis
Details
A short screen capture video which shows the issue (259.23 KB, video/mp4)
2014-08-07 12:00 UTC, Matthew Francis
Details
stack trace debug build (81.83 KB, text/plain)
2014-10-15 15:33 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-08-07 11:59:05 UTC
Observed on OSX 10.9.4 / LO 4.3.0.4:

Steps to reproduce:
1. Open a new Writer document and start entering some Japanese text
2. While still pre-editing the text (i.e. before pressing "Return"), change the text style (e.g. font, bold, etc.)
3. Cancel the Japanese input with "Esc"
4. Undo
5. Start entering some more Japanese text

At (5), the input method should engage again, but in fact weirdness occurs until several more characters have been typed. See the attached video for an example.

I think the undo stack is getting corrupted by this sequence - changing the text style pushes an undo for the change, but cancelling the input deletes all the text that had been typed without removing this, so the undo operation in (4) is operating on text that isn't there any more


When I try the same thing on a recent build from source (4.4.0.0.alpha0+) it actually goes one further and crashes at (4). Backtrace also attached for this following.


(A comment on bug 82115 has some assistance on setting up Japanese input if required)
Comment 1 Matthew Francis 2014-08-07 11:59:54 UTC
Created attachment 104222 [details]
Backtrace from crash under 4.4 git
Comment 2 Matthew Francis 2014-08-07 12:00:52 UTC
Created attachment 104223 [details]
A short screen capture video which shows the issue
Comment 3 Alex Thurgood 2014-10-15 15:32:24 UTC
Confirming crash on 440 master, stack trace from debug build attached
Comment 4 Alex Thurgood 2014-10-15 15:33:29 UTC
Created attachment 107888 [details]
stack trace debug build
Comment 5 Mark Hung 2015-09-07 23:42:37 UTC
*** Bug 87500 has been marked as a duplicate of this bug. ***
Comment 6 QA Administrators 2016-09-20 10:28:57 UTC Comment hidden (obsolete)
Comment 7 eisa01 2018-06-14 21:23:23 UTC
This is still present, but I'm not seeing any crash. Tested with Hiragana input method

Note, on step 3, press Esc twice to cancel the Japanese input

Lowering importance as this is quite an edge case, I can not remember ever trying something similar while writing English.

Was also present on LO 3.3, so inherited

Version: 6.2.0.0.alpha0+
Build ID: b292a27698e85fd9d60c03613c3b0c67835c4dc1
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-06-06_23:25:55
Locale: en-US (en_US.UTF-8); Calc: group threaded
Comment 8 QA Administrators 2019-06-15 02:59:45 UTC Comment hidden (obsolete)
Comment 9 eisa01 2019-08-10 20:07:00 UTC Comment hidden (obsolete)
Comment 10 eisa01 2020-05-21 11:47:58 UTC
Still occurs

1. Switch to Hiragana
2. Type a couple 'a' keystrokes
3. Change font (I used a font with similar symbols)
4. Press escape twice to exit Japanese input mode (you then have a blank document)
5. Press cmd+z (undo apply attributes)
6. Type a couple 'a' keystrokes and observe a multitude of characters appear

Crash no longer relevant

Version: 7.0.0.0.alpha0+
Build ID: f14691683900f6b28737be8c599e1ee4e8386e14
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
Comment 11 QA Administrators 2022-05-22 03:43:07 UTC
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