Bug 1573923 - GDM login screen does not honour the selected keyboard language
Summary: GDM login screen does not honour the selected keyboard language
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 28
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1574523 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-02 14:13 UTC by Tich
Modified: 2018-06-06 14:35 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 14:35:02 UTC
Type: Bug


Attachments (Terms of Use)
possible fix (4.12 KB, patch)
2018-05-04 22:22 UTC, Ray Strode [halfline]
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-shell merge_requests 98 0 None None None 2018-05-07 14:33:42 UTC

Description Tich 2018-05-02 14:13:46 UTC
Description of problem:

GDM login screen does not follow the selection made in regard of keyboard language, using always EN one 

Version-Release number of selected component (if applicable):

gdm-3.28.1-1.fc28.x86_64


How reproducible:

100%
Everytime I type my password with the Spanish (ES) keyboard selected, it types as if I had the English (EN) one selected

Steps to Reproduce:
1. Select ES 
2. Type username or password
3. See how it uses EN map instead of ES everytime (preventing logging if you use special characters for wich EN an ES are different)

Actual results:

Username and password typed with the selected language keyboard mapping

Expected results:

Username and password typed as if I was using EN keyboard mapping

Additional info:

FC27 just upgraded to FC28
Console login works fine with ES, as well as the GNOME session once logged in

Comment 1 Kamil Páral 2018-05-04 14:40:56 UTC
Proposing as a PrioritizedBug because this prevents login if you have characters in your password that you can't type with English keyboard.

Comment 2 Kamil Páral 2018-05-04 14:42:04 UTC
*** Bug 1574523 has been marked as a duplicate of this bug. ***

Comment 3 Jiri Eischmann 2018-05-04 14:51:01 UTC
I don't think it doesn't honor or ignore layout settings, it somehow gets the order wrong. I've got Czech as primary layout and English as secondary. GDM is set to Czech by default, the indicator says, but in fact the set layout is EN, but when I switch to EN (either in the indicator menu or by pressing super-space), then I get the Czech layout. So it's:

CS->EN
EN->CS

Not:
CS->EN
EN->EN

Comment 4 Kamil Páral 2018-05-04 15:07:04 UTC
Confirmed. This does not prevent entering non-ascii passwords, just the indicator doesn't reflect the current keyboard. So you might need to choose English to get your (Czech, Spanish, etc) keyboard. You can right click the password field and use Show Text to see what you're entering.

Comment 5 Tich 2018-05-04 19:50:00 UTC
In my case, I have Spanish (ES) as my default choice, which as you mention, is really behaving as English (EN), but it does not matter which one I select or in which order I do it, the layout seems to be always the English one. It does not prevent login, provided you realize about this and know the English mapping, which is the case hopefully.

One I log into the system, the keyboard layout is correct, and when the screen gets locked, it honors my session keyboard mapping also. In my case, this missmatched behaviour does only occur on the login screen.

Comment 6 Ray Strode [halfline] 2018-05-04 22:22:52 UTC
Created attachment 1431625 [details]
possible fix

can someone seeing this try scratch build (when it finishes):

https://koji.fedoraproject.org/koji/taskinfo?taskID=26772549

and see if fixes the problem and also doesn't regress bug 1569211 ?

Comment 7 Adam Williamson 2018-05-05 06:17:17 UTC
Did this break some time after release? Because openQA has a test for this, and it passed:

https://openqa.fedoraproject.org/tests/231864

the password used in that test is entered in both Latin and Cyrillic characters. It shouldn't have worked with this bug. Or does this bug only happen if the primary layout is not US?

Comment 8 Helge 2018-05-05 07:35:14 UTC
(In reply to Adam Williamson from comment #7)
> Did this break some time after release? Because openQA has a test for this,
> and it passed:
> 
> https://openqa.fedoraproject.org/tests/231864
> 
> the password used in that test is entered in both Latin and Cyrillic
> characters. It shouldn't have worked with this bug. Or does this bug only
> happen if the primary layout is not US?

For me it happens since the recent gdm update to gdm-1:3.28.1-1.fc28.x86_64. Before (I installed the F28 RC) everything worked fine.

Comment 9 František Zatloukal 2018-05-05 09:47:01 UTC
(In reply to Ray Strode [halfline] from comment #6)
> Created attachment 1431625 [details]
> possible fix
> 
> can someone seeing this try scratch build (when it finishes):
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26772549
> 
> and see if fixes the problem and also doesn't regress bug 1569211 ?

Fixed the issue, also, didn't regress 1569211 for me.

Comment 10 Helge 2018-05-05 14:43:09 UTC
(In reply to Ray Strode [halfline] from comment #6)
> Created attachment 1431625 [details]
> possible fix
> 
> can someone seeing this try scratch build (when it finishes):
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26772549
> 
> and see if fixes the problem and also doesn't regress bug 1569211 ?

Works for me as well, thanks!

Comment 11 Garrett Hyde 2018-05-07 14:10:55 UTC
(In reply to Ray Strode [halfline] from comment #6)
> Created attachment 1431625 [details]
> possible fix
> 
> can someone seeing this try scratch build (when it finishes):
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26772549
> 
> and see if fixes the problem and also doesn't regress bug 1569211 ?

Works for me, too.

Comment 12 Ray Strode [halfline] 2018-05-07 14:23:44 UTC
(In reply to Helge from comment #8) 
> For me it happens since the recent gdm update to gdm-1:3.28.1-1.fc28.x86_64.
> Before (I installed the F28 RC) everything worked fine.
Probably a coincidence. GDM doesn't have anything to do with the layout used on the login screen.

Comment 13 Ray Strode [halfline] 2018-05-07 14:25:53 UTC
(In reply to Adam Williamson from comment #7)
> openQA has a test for this, and it passed:
> 
> https://openqa.fedoraproject.org/tests/231864
> 
> the password used in that test is entered in both Latin and Cyrillic
> characters. It shouldn't have worked with this bug. Or does this bug only
> happen if the primary layout is not US?
i'm not too clear on exactly what leads up this problem happening, to be honest.  if you change the test to do german and english instead does it start reproducing ?

Comment 14 Christian Stadelmann 2018-05-12 17:04:42 UTC
(In reply to Tich from comment #5)
> In my case, I have Spanish (ES) as my default choice, which as you mention,
> is really behaving as English (EN), but it does not matter which one I
> select or in which order I do it, the layout seems to be always the English
> one. It does not prevent login, provided you realize about this and know the
> English mapping, which is the case hopefully.
> 
> One I log into the system, the keyboard layout is correct, and when the
> screen gets locked, it honors my session keyboard mapping also. In my case,
> this missmatched behaviour does only occur on the login screen.

Same here except that I'm using 2 German layouts before the English layout. Still, no matter how I configure it, it always uses the English layout on the login screen. Everything else works fine.


(In reply to Ray Strode [halfline] from comment #6)
> Created attachment 1431625 [details]
> possible fix
> 
> can someone seeing this try scratch build (when it finishes):
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26772549
> 
> and see if fixes the problem and also doesn't regress bug 1569211 ?

Works fine, no regression. Thank you very much!

Comment 15 Tich 2018-05-25 14:01:17 UTC
With my system fully updated (running kernel 4.16.11-300.fc28.x86_64) the problem seems to have vanished.

Comment 16 Adam Williamson 2018-05-25 15:48:03 UTC
Ray: "i'm not too clear on exactly what leads up this problem happening, to be honest.  if you change the test to do german and english instead does it start reproducing?" - unfortunately "change the test" there would have been several hours of work (as we have to add variant screenshots for quite a lot of screens when we add a new language test, because, well, all the text is translated :>). But yeah, if it's an ordering issue, it kinda makes sense, because in the Cyrillic case the initial layout is expected to be us (not ru).

Anyhow, looks to me like the 3.28.2 megaupdate - https://bodhi.fedoraproject.org/updates/FEDORA-2018-6ae44e601e - should have been marked as fixing this, as the merge request you linked was apparently included in 3.28.2. So, should we just go ahead and close this now?

Comment 17 Ray Strode [halfline] 2018-06-06 14:35:02 UTC
let's close it


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