#1913 Spurious InputMethodEvents on qt5 / Linux

[John Ehresman]

I'm seeing InputMethodEvents with empty preedit and commit strings sent when alt-tab is used to switch away from the app on ubuntu 16.10. The problem is that anything selected gets deleted in preparation for inserting the strings. This is probably a bug with qt 5.5 but I think scintilla should work around it.

Attached is a patch that ignores events with the two strings empty except when the tentative undo is active (because the tentative needs to be undone and replaced with a ''). Do you see any problem with this?

[johnsonj]

I can not reproduce it with fcitx for Qt5.5.1 on lubuntu 16.04.
Maybe other imes might return no ime string.
I saw the case no ime string comes when reconvert key is hitted.

if selection is replaced with "" when no ime string comes (hitting alt-tab),
the culprit is ClearBeforeTentativeStart() rather than TentativeUndo().

I guess this patch may work:
https://groups.google.com/group/scintilla-interest/attach/35df9aa68bc2d9/initialCompose.patch?part=0.1&authuser=0&view=1

I hope it may please your need.

[John Ehresman]

Yes, the actual deletion is done by ClearBeforeTentativeStart(). I think the patch that moves this call into the !preeditString.isEmpty() block has the problem that if there is no preedit string, the selected text won't be deleted before the commitString is added.

There are four cases when 2 events are sent:
1) preedit != '', commit != ''
2) preedit == '', commit != ''
3) preedit != '', commit == ''
4) preedit == '', commit == ''

I'm trying to change things so that in case 4, no change is made to the text. Arguably, in case 3 no change should be made either, though that's a bit more difficult because undo doesn't track what the selection was.

I'm seeing the problem with a US English keyboard with no entry of anything that require an input method event.

[johnsonj]

I am sorry your message is overwritten by wrong button down.
I have restored it from my email.

initialCompose.patch will work as same as ingnore-empty-strings.diff:
Do nothing if both no ime string comes in no composition mode.

I have have never seen case 1.
Case 3 means there is no selecion.
Case 4 means reconversion before ime input.

I see Scintilla 3.7.3(unpatched) keeps selection when alt-tab hitted for Qt5.5.x:
windows xp, windows 7, lubuntu 16.04, fedora 24.

I am installing lubuntu 16.10

[johnsonj]

I can not reproduce it with fcitx for Qt5.6.1 on lubuntu 16.10.
I can not reproduce it with no ime for Qt5.6.1 on lubuntu 16.10.

[johnsonj]

"""if there is no preedit string, the selected text won't be deleted before the commitString is added."""
Why Is this a problem?

[Neil Hodgson]

Neither of the patches retain the entered text for me.

My setup:
Ubuntu 16.10.
Settings:
Language Support:
Install Japanese
Keyboard input method system: IBus
Text Entry:
Add input source: Japanese (Mozc) (IBus)
Build scintilla/qt/ScintillaEditBase.
Download and build www.scintilla.org/Haven.zip.

Run Haven.
In Haven, choose Encoding | UTF-8.
In language menu at top right of screen:
Select Mozc
Select Input Mode | Hiragana
At end of text type "kata" to produce pre-edit text "かた".
Alt+Tab to Firefox (or other app).
Pre-edit text "かた" disappears.
Alt+Tab back to Haven.
No Japanese text.

I see the same behaviour with current Scintilla and with the ignore-empty-strings.diff patch and with the initialCompose.patch patch.

SciTE (GTK+) behaves differently: when the Alt key is pressed, the pre-edit text is committed to the document.

With original Scintilla code (no patch applied) fcitx (chosen in Language Support) + Mozc, the pre-edit text is committed, but slightly differently to SciTE/GTK+, occurring when Tab is released, not when the Alt is pressed.

[John Ehresman]

The original bug is that text is deleted when there's a selection and alt-tab is pressed. No input needs to occur before alt-tab. This happens in a US environment where input contexts are rarely, if ever used. I don't know why Qt is sending input method events on alt-tab, but it is and I want to avoid building Qt and trying to figure out why.

[Neil Hodgson]

OK, I misunderstood. Does this happen for you with Haven and unpatched Scintilla? I'm not seeing it myself with English | US. Does it occur on pressing Alt or when the other app receives focus?

[John Ehresman]

I've reproduced with Haven, scintilla from hg, and the ubuntu supplied qt5 on Ubuntu 16.10 (64 bit). I can run Haven and it comes up with the word main selected -- then I press and release the left control key, then press alt-tab. The word main is deleted from the Haven window. I haven't verified that this is due to input method events, but it looks like the same bug. I have only the English (US) keyboard selected it the text entry system settings. I'm also using VMware Fusion to run ubuntu in and I'm using the default ubuntu desktop.

I just tried it a few more times and it is intermittant, but I can usually get it to fail within 5 tries.

[Neil Hodgson]

So, the problem is never seen without the initial left control? Its possible that left control is bound to a VMWare action or is interpreted as a potential mode switch. I'm using VirtualBox 5.1.14 to run Linux and don't see this and I tried changing the Host key from right control to left control - didn't occur with right or left control with either setting. I don't have a (current) system which could easily take a Linux partition but may try to get an older machine running later.

VMware Fusion may be trying to fuse more state than VirtualBox with a joined clipboard or input key mechanism - perhaps trying to maintain the same input language and partial entry state on both sides.

My host system is Windows 10 and I'd assume yours would be macOS 10.12.

With VMWare Fusion, can Alt+Tab move from a Linux window directly to a macOS window? That is, is there a single list of active windows from both operating systems that Alt+Tab iterates through? VirtualBox separates the sessions more than that.

[John Ehresman]

It's happened w/o the initial control press. I use vmware in its desktop in a window mode so the ubuntu screen appears in a single macOS window and alt-tab stays exclusively in the ubuntu screen. This bug was initially reported by a Wing user and I've asked him about the details of his system.

Even if this is a bug in qt / ubuntu / vmware / something, it's fixable in scintilla -- and it seemed like random deletion of text until I tracked it down and random text deletion isn't a good thing in a text editor :). My question really is whether there could be a legitimate reason to delete text in my case 4 in the 3rd comment in this thread.

[Neil Hodgson]

As johnsonj said, case 4 occurs for reconversion which is where you select some characters and ask the IME to have another try at finding a match that you prefer. Reconversion is not currently supported by Scintilla for Qt although it is by Scintilla for Win32. Johnsonj has contributed patches for reconversion for Qt which work with fcitx on Linux but not, I think, IBus.

To see reconversion on Windows, configure the Japanese language support and display the IME Pad window from the Japanese IME menu. Select some Japanese text in SciTE and press the "Conv" button on the IME Pad. A menu appears with related texts.

Try the same thing with Haven and some traces in ScintillaEditBase::inputMethodEvent or use a debugger and you should see empty pre-edit and commit strings with the "Conv" key.

While reconversion is not yet supported by Scintilla on Qt, I wouldn't want to preclude it with an early exit like the patch.

[John Ehresman]

The Wing user who reported this originally has 2 desktops with ubuntu 16.04 and a laptop with ubuntu 16.10. No vmware; docker engine is installed but not active (and I don't think it would be a factor anyway). Keyboard is swiss. Bug is seen on all three systems.

In the reconvert case, are there multiple input context events? In my case 4, I meant that 2 events are being sent, both with empty commit and preedit strings.

[Neil Hodgson]

Reconversion normally follows the initial clear call with one that sets a candidate in the pre-edit. However, if there is no good candidate then there is no candidate pre-edit. Then, a second attempt without a good candidate will repeat the empty message, This can be demonstrated by trying to reconvert a space but it may also be possible with more sensible text - my CJK skills are limited. Its also going to be dependent on the behaviour of the particular IME as IMEs require applications to process their messages reasonably to add features.

The video file didn't work on a Mac inside Mail or with the QuickTime player and the Windows 10 video player showed blank. Video files often fail so, if its not confidential, uploading to YouTube and posting the URL is more likely to work.

European language modes may use IME features for accents where a dead key is first pressed for the accent then the base character. So '^' then 'a' for 'â'. Its possible some component is trying to flush this state out. On my Ubuntu setup, using dead accents for German delivers the final accented character (like 'á') through the commit string but there is no pre-edit containing just the accent. Unaccented characters like 'a' do not go through the inputMethodEvent call. The acccent-entered state is invisible and survives an Alt+Tab out and then back.

[johnsonj]

There comes only one event: ime input context is passed.
QInputMethodEvent *event

I use this statement for reconversion.
+ if (event->commitString().isEmpty() && event->preeditString().isEmpty()) {

https://groups.google.com/group/scintilla-interest/attach/b0de76fd21589/rcQt1212.patch?part=0.1&view=1

[John Ehresman]

The video I sent to Neil is playable for me with VLC; the only thing it shows though is the selection being deleted after a ctrl-c and then a alt-tab.

I've found how to load symbol files on ubuntu -- see https://wiki.ubuntu.com/Debug%20Symbol%20Packages -- and can get a reasonable backtrace. The input event method is being generated by a QIBusPlatformInputContext::updatePreeditText method in response to a dbus rpc call (I think). Neil's idea that alt is seen as a compose key and the preedit sting is being cleared is probably correct.

When reconverting, does the initial event specify that some characters should be deleted? If not, I wonder if it's assumed that sending a 2nd im event with a commit string == '' will revert the buffer back to its state before the 1st im event?

[Neil Hodgson]

Is there a way to perform reconversion on Linux with easily accessible IMEs now? Last time we were discussing this, I think it required using a version of fcitx which is not provided by the distributions or their app stores so had to be downloaded and built.

I'm wary of changing Scintilla in a way that we expect to eventually revert (for reconversion) as that means that a future release will worsen the behaviour for some people.

Johnsonj's second patch looks at the replacementLength for the number of characters to delete. If replacementLength() returns 0 for the application switch event then that may allow avoiding the deletion.
The source for QIBusPlatformInputContext::updatePreeditText appears to be treating empty text as a cursor movement request.
https://github.com/Satius/qt5/blob/master/qtbase/src/plugins/platforminputcontexts/ibus/qibusplatforminputcontext.cpp

[johnsonj]

Standard fcitx and lubuntu 16.04 pure has been used for reconversion.
Reconversion should follow mutual protocol between application and ime.
if eplacementLength() returns 0, that result might moving carets.
Alt-tab key might make this case.
but I think this case is unreasonable for reconversion key.

reconversion protocol follows:
it deletes the existing strings,
it sends preedit strings
Finally committed strings are sent.

So we need only existing target strings and caret position.
Anchor position can be calculated to caretPos+stringLength or caretPos-stringLength.

I think these are enough to keep.

Three cases has been shown.
1. korean (no selection)
2. japanese (selection)
3. english (accented input)

Reconversion has been proved useful even for no ime user.

I do not insist reconversion feature to be commited.
but this patch should be applied as soon as possible.
It is not for just efficience but also now for coping with no ime string.
https://groups.google.com/group/scintilla-interest/attach/35df9aa68bc2d9/initialCompose.patch?part=0.1&authuser=0&view=1

[Neil Hodgson]

Standard fcitx and lubuntu 16.04 pure has been used for reconversion.

What action is done to perform reconversion on lubuntu 16.04 with fcitx? Perhaps there is a key binding? Does an fcitx addon have to be enabled or configured?

Reconversion has been proved useful even for no ime user.

Which would be great if I could trigger it on Linux.

On Win32, the rcQt1212.patch leads to some poor behaviour with Japanese. If the selection is backwards (from last to first), as would occur if you chose the wrong candidate then immediately Shift+Left to fix, then the selection is deleted and a candidate list shows two entries with spaces. If the selection is forwards then there is a candidate list with some single character entries but it is not a similar list to that which appeared after typing that text.

but this patch should be applied as soon as possible.
It is not for just efficience but also now for coping with no ime string.

OK, committed as [225f39].