Bugzilla – Bug 1094584
[Build 20180522] multi_users_dm: no keyboard input
Last modified: 2022-02-10 15:14:07 UTC
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_on_gnome@64bit fails in
Fails since (at least) Build (https://openqa.opensuse.org/tests/681463)
## Expected result
Last good: (https://openqa.opensuse.org/tests/680945) (or more recent)
## Further details
Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?machine=64bit&arch=x86_64&flavor=DVD&test=extra_tests_on_gnome&version=Tumbleweed&distri=opensuse)
From the looks of it, the keyboard presses are not longer honored by gdm/gnome-shell. This snapshot included an update of gnome-shell, which is a good candidate to check for this kind of regression
I guess it is related with
and two commits in mutter:
It moves mouse pointer to low right corner from center on gdm login screen.
I tested on the real machine, press 'tab' key first, inputting focus can be moved to user list, then move 'up' or 'down' key, you can select user.
Should be fixed with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5127
fixed in https://openqa.opensuse.org/tests/682445
The old method relied on a preselected user entry in the middle of the screen (maybe by mouseover?) and pressed arrow up until user#01 was selected.
When there is no prior selection, this will not work.
Therefore the new code will send [tab] until user#01 is selected.
Do we consider this behaviour change as a bug?
(In reply to Dominik Heidler from comment #4)
> fixed in https://openqa.opensuse.org/tests/682445
> The old method relied on a preselected user entry in the middle of the
> screen (maybe by mouseover?) and pressed arrow up until user#01 was selected.
> When there is no prior selection, this will not work.
> Therefore the new code will send [tab] until user#01 is selected.
> Do we consider this behaviour change as a bug?
Seems nobody considers this a bug