Changing focus with pre-edit buffer candidate types it in other window

[IBBoard]

Please fill in the following items if you don't know the root cause.

Which distribution and version?:
openSUSE Tumbleweed

Which desktop environment and version?:
Gnome 3.30

Which session type?:
X11

Which application and version?:
From any (GTK?) app to Mozilla apps

(Tested Corebird 1.7.4, Geany 1.33 and GEdit 3.30 to Firefox 63.0.3 and Thunderbird 60.3.1)

IBus version?:
"compose-tentative" branch

Issue description:
If you type a pre-edit candidate in "compose" mode and then focus Firefox and type a character then the pre-edit candidate will be typed before the character you typed. The same behaviour doesn't happen between Firefox and other apps, or between other apps.

This may be a Firefox bug, but I didn't know whether there was something that ibus isn't cancelling soon enough that Firefox is picking up on but other (GTK?) apps are handling correctly.

Steps to reproduce:

1. Create XCompose with overlapping definitions - e.g. "Multi Multi a" for α and "Multi Multi a t o m" for ⚛
2. Open GEdit
3. Type "Multi Multi a". Pre-edit "α" appears
4. Click in to an input box in Firefox (either in a page or the address bar)
5. Type a letter (e.g. "b")

Expected behaviour: Pre-edit is cancelled in GEdit. Firefox types "b".

Actual behaviour: Pre-edit is cancelled in GEdit. Firefox types "αb"

Can you reproduce your problem when you restart ibus-daemon? (yes / no):
Yes

Do you see any errors when you run ibus-daemon with the verbose option?:
No

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):
Not tested

[fujiwarat]

The same behaviour doesn't happen between Firefox and other apps, or between other apps.

I think the result is same. Did you use Alt-tab?

[IBBoard]

Ah, it seems to differ slightly between Alt-Tab and click-to-focus behaviour! I was just clicking between apps before.

• It happens from other apps to Firefox/Thunderbird on click
• It happens between Firefox and Thunderbird on click
• It doesn't happen from Firefox/Thunderbird to other apps on click
• It doesn't happen between other GTK apps (gEdit, Geany, Corebird) on click
• But it does happen in both directions on all apps (including between GTK apps) when I use Alt-Tab!

Oddly, I've also noticed that Firefox leaves the pre-edit text behind as final text when it's the origin app (so the α appears in both apps), but other apps cancel the pre-edit and don't leave α behind in the origin app. That seems to be to do with how it handles focus change while there's pre-edit text rather than being triggered by the subsequent typing, though.

[fujiwarat]

I think your testings are in the much better progress.

It doesn't happen between other GTK apps (gEdit, Geany, Corebird) on click

Seems you clicked the input fields instead of the title bars of the windows or you didn't install a patch.

I think now other two patches resolve this issue in https://github.com/fujiwarat/ibus/commits/compose-clear-focus
fujiwarat@4c40afb
fujiwarat@7f976b3

NOTE: you need to update both GTK2 and GTK3 im-ibus.so of the patches.

Firefox has an ability to commit the preedit forcibly for some reasons (I don't know why but Firefox has several features likes prediction features) and the current ibus overrides it and lets each ibus engine choose the clear or commit but I will change the behavior later again after I close this issue.

1. Firefox always commit the preedit in any IBus engines.
2. IBus engines will choose to commit or clear the preedit in other GTK applications and IBus compose engine will choose to clear the preedit.

[IBBoard]

It doesn't happen between other GTK apps (gEdit, Geany, Corebird) on click

Seems you clicked the input fields instead of the title bars of the windows or you didn't install a patch.

Strange. I was running "compose-tentative" built from Git, so it should have had that patch. I can't recreate the bug on click between GTK apps, though (either by clicking the title bar or straight in to an input box)

I think now other two patches resolve this issue

Confirmed - I can't seem to trigger the bug when running fujiwarat/ibus@7f976b3

Firefox has an ability to commit the preedit forcibly for some reasons (I don't know why but Firefox has several features likes prediction features)

This does still seem to happen (Firefox turns the pre-edit text into finalised text on focus change), but it sounds like you're treating that as a separate issue.

Thanks.

[fujiwarat]

Thank you for your test.