Bug 1552668 - Gnome: ibus input methods are active on the screen locker password input
Summary: Gnome: ibus input methods are active on the screen locker password input
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F28FinalFreezeException
TreeView+ depends on / blocked
Reported: 2018-03-07 13:57 UTC by Mike FABIAN
Modified: 2018-04-16 14:03 UTC (History)
11 users (show)

Clone Of:
Last Closed: 2018-04-16 14:03:33 UTC

Attachments (Terms of Use)
input-methods-are-active-on-the-screen-lock-password-input-of-gnome.png (262.37 KB, image/png)
2018-03-07 13:57 UTC, Mike FABIAN
no flags Details

Description Mike FABIAN 2018-03-07 13:57:24 UTC
Created attachment 1405348 [details]

I installed Fedora-Workstation-netinst-x86_64-28-20180302.n.0.iso in qemu
in Japanese.

After logging into Gnome and waiting for the screen locker to lock
the screen, I found that input methods are active on the password
input field of the screen locker. 

See attached screenshot.

This affects apparently all ibus input methods, not only
the Japanese ibus-kkc shown in the screenshot, the same
problem occurs for example with ibus-typing-booster.

Comment 1 Fedora Blocker Bugs Application 2018-03-08 08:36:49 UTC
Proposed as a Freeze Exception for 28-final by Fedora user petersen using the blocker tracking app because:

 ibus should be disabled on the lockscreen and password gui fields

Comment 2 fujiwara 2018-03-08 12:08:15 UTC
st_entry_set_input_purpose() in gnome-shell 3.24 calls st_im_text_set_input_purpose() and treats GtkIMContext.
But st_entry_set_input_purpose() in gnome-shell 3.26 or later calls clutter_text_set_input_purpose() and it does not work with IBus GTK IM module.

Comment 3 Carlos Garnacho 2018-03-13 15:44:26 UTC
I just filed https://gitlab.gnome.org/GNOME/mutter/issues/66 upstream.

Some clarifications on what happened on 3.27/28 (not 3.26), the compositor-side rework basically cut two middle men here:

- StIMText, whose sole role was involving GTK+/GtkIMContext in key event processing
- GtkIMContext itself, in favor of a ClutterInputMethod. The implementation that talks to ibus is in gnome-shell/js/misc/inputMethod.js

So the processing flow inside the compositor has gone from:




Barring bugs, IBus should see the same requests, simply from an IBusInputContext in a different wrapper.

Comment 4 fujiwara 2018-03-14 05:26:23 UTC
(In reply to Carlos Garnacho from comment #3)
> I just filed https://gitlab.gnome.org/GNOME/mutter/issues/66 upstream.

I verified #66 and #65 and hope the fixes are on time in Fedora 28.

Seems I installed 3.27 in Fedora 27 for other issues. Today I cannot reproduce this in Fedora 27.

Comment 5 Geoffrey Marr 2018-04-02 17:21:39 UTC
Discussed during the 2018-04-02 blocker review meeting: [1]

The decision to classify this bug as an AcceptedFreezeException was made as this is incorrect for input method-based languages and can affect authentication on the first boot after install.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-04-02/f28-blocker-review.2018-04-02-16.00.txt

Comment 6 Kalev Lember 2018-04-16 10:47:33 UTC
The upstream PR is included in mutter 3.28.1 that's in updates-testing. Can you test that it works correctly now, please?

Comment 7 Mike FABIAN 2018-04-16 13:41:10 UTC
(In reply to Kalev Lember from comment #6)
> The upstream PR is included in mutter 3.28.1 that's in updates-testing. Can
> you test that it works correctly now, please?

If I have Japanese input active and wait for the screen locker to kick in,
when I try to type the password, it switches to a keyboard layout
(English in my case, probably because this is first in the list, I have
English layout and Japanese layout configured).

So I think it works now, the input method is not active on the lock screen.

The switch to the English keyboard layout is not only for entering
the password though, after unlocking the screen locker, the English
layout is still selected.

I.e. it does not remember that the Japanese input method was active
when the screen locker kicked in and does not return to the Japanese input method. It would probably be more convenient if it remembered the last
active input method before the screen lock started. But I don’t remember whether it did  that in Fedora 27, so it might not be a regression.

Anyway, it works now, thank you!

Comment 8 Kalev Lember 2018-04-16 14:03:33 UTC
OK, let's close this then as the update fixing things is headed to stable updates. Thanks for verifying!

Note You need to log in before you can comment on or make changes to this bug.