Bug 1552668
| Summary: | Gnome: ibus input methods are active on the screen locker password input | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mike FABIAN <mfabian> | ||||
| Component: | mutter | Assignee: | Florian Müllner <fmuellner> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 28 | CC: | bugzilla.redhat.com, cgarnach, fmuellner, gmarr, klember, mfabian, otaylor, petersen, tagoh, tfujiwar, walters | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | AcceptedFreezeException | ||||||
| Fixed In Version: | mutter-3.28.1-1.fc28 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-16 14:03:33 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1469207 | ||||||
| Attachments: |
|
||||||
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 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. 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: StEntry->StIMText/ClutterText->GTK+->GtkIMContext->IBus to: StEntry->ClutterText->ClutterInputMethod->IBus Barring bugs, IBus should see the same requests, simply from an IBusInputContext in a different wrapper. (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. 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 The upstream PR is included in mutter 3.28.1 that's in updates-testing. Can you test that it works correctly now, please? (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! OK, let's close this then as the update fixing things is headed to stable updates. Thanks for verifying! |
Created attachment 1405348 [details] input-methods-are-active-on-the-screen-lock-password-input-of-gnome.png 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.