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
Proposing as a PrioritizedBug because this prevents login if you have characters in your password that you can't type with English keyboard.
*** Bug 1574523 has been marked as a duplicate of this bug. ***
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
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.
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.
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 ?
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?
(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.
(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.
(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!
(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.
(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.
(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 ?
(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!
With my system fully updated (running kernel 4.16.11-300.fc28.x86_64) the problem seems to have vanished.
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?
let's close it