Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.15.1
-
None
-
Windows Server 2012 R2 (I expect it will have same behavior on Windows 10 but I did not at the moment have access to a machine with proper working IME installation)
-
Windows
Description
When using IME input method in QPlainTextEdit, the contentsChange signal behaves very differently from the behavior expected from typing ASCII / latin characters.
For example, when typing the character 'a':
| Parameter | Latin | IME (Fullwidth Alphanumeric) |
|---|---|---|
| pos | actual position of edit | start of line position |
| removed | 0 | old length of line + 1 |
| added | 1 | old length of line + 1 |
Also, the contentsChange event occurs for every character that is typed even though the contents of the document did not actually change yet (toPlainText() still shows the old text while the "underlined" temporary text under IME control is not yet part of the document content). We assume this reveals some internal behavior as IME and text edit steal / pass event to / from each other.
Our biggest problem with this is that some events become ambiguous. For example
removed = 10, added = 1
typically means a selection of 10 characters was replaced by a single character. However now it can also mean a selection of 9 characters was removed by typing into IME, with no actual character added (yet).
Background: The text typed into our widget is parsed on-the-fly to build a structured representation. For performance reasons this structure is adapted incrementally on each edit. Unexpected values of the contentsChange notification can cause text and model to become out of sync potentially causing erratic behavior for our Japanese customers.
The attached test program demonstrates the behavior. To reproduce,
- Set focus to the upper left text box
- Select japanese language input in task bar
- Switch input mode to 'Fullwidth Alphanumeric' in task bar
- Begin typing characters
The contentsChange events will be printed in the lower text box. The plain text content of the document is mirrored in the upper right text box so we can observe that events occur also before the actual content changes
There also seems to be a related bug regarding loss of focus during IME edit operation. Interrupting IME entry by clicking with mouse on the lower output text box will cause the current text to be added to the document (including contentsChange event). However the IME edit operation has not actually finished. When clicking back into the upper left text box with the mouse and pressing return the text is added twice.
Desired behavior:
- contentsChange event occurs only if content has actually changed
- there should never be a report on a "virtual character" that was never actually in the content ("removed = 1 added = 1" with semantics of first added then removed)
- cleanly handle aborted input (e.g. focus loss, pressing "ESC" key, making an "empty" IME edit by type + backspace + return, ...)
Nice to have
- Properly report position of actual edit
- But if entire line is reported as changed it is fine as long as values are consistent (identical to selecting old line text and pasting new line text)