Assure focused password textbox

[SergioAtSUSE]

• Related ticket: https://progress.opensuse.org/issues/46223
• Related bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1122664
• Merge needles first:
  • Use available screenshot to assert an unfocused textbox os-autoinst-needles-opensuse#499 reverted
  • Add needle with focused textbox and visible cursor os-autoinst-needles-opensuse#505
• Verification run: http://slindomansilla-vm.qa.suse.de/tests/1190

[okurz]

Shouldn't the password prompt be always selected? This worked in before so either we have a bug that we do not want to hide or something else is broken but I would like to not just silently accept faulty product behaviour.

[okurz]

and again this can not work reliably because check_screen has a 0 timeout, meaning there is no waiting between the former selection of user and the password prompt.
Please use a multi-tag assert_screen with match_has_tag instead of check_screen with non-zero timeout to prevent introducing any timing dependant behaviour, to save test execution time as well as state more explicitly from the testers point of view what are the expected alternatives. For example:

assert_screen([qw(yast2_console-finished yast2_missing_package)]);
if (match_has_tag('yast2_missing_package')) {
    send_key 'alt-o';  # confirm package installation
    assert_screen 'yast2_console-finished';
}

[SergioAtSUSE]

With a blinking cursor, using multi-tag assertion you have 50% of chances of getting false positives. But, anyway I just realized that asserting an unfocused textbox is also wrong. Because the unfocused textbox looks the same as a focused textbox at an instant when the cursor is off.

[okurz]

1. There is the option "no_wait" on e.g. assert_screen to cover "blinking cursor" if you must
2. Better avoid the blinking cursor, e.g. with a proper needle design, could be an exclude area
3. Are you sure unfocussed looks the same as focussed but cursor off? If you mean by "cursor off", while it's blinking I remember in gdm that there is still a small white border around the box

[SergioAtSUSE]

1. assert_screen will break the test on unfocused textbox
2. We are exactly trying to match this area, we cannot exclude it.
3. Yes, see: https://progress.opensuse.org/issues/46223#note-6

[SergioAtSUSE]

@okurz, what do you think now?

[rwx788]

I wonder why not to use multitag assert here or that's not possible to catch unfocused password prompt?
Advantage will be that if password prompt is unfocused, we won't wait for 30 seconds before selecting it.

[okurz]

+1 what @rwx788 says, the check_screen is a no-go for me here

[SergioAtSUSE]

Yes, it is not possible.

As I stated here: #6596 (comment)

And I explained it here: https://progress.opensuse.org/issues/46223#note-6

Comparing this job where it worked with a failing one:

• Passed: https://openqa.opensuse.org/tests/832459#step/user_gui_login/5
  with
• Failing: https://openqa.opensuse.org/tests/831695#step/user_gui_login/6

There is no difference between a focused textbox from a non-focused textbox. If you try to verify if it is not focused, you get false positives, since there is a 50% chance (it really depends on the blinking frecuency, but you get the point) of getting an focused textbox without cursor.
The only thing we can be sure is that if we see the cursor, it is focused, and to avoid the test to fail, I need check_screen.

[okurz]

But the two screens look quite different. Maybe only very subtle a one-pixel border around the entryfield which looks like black-on-black but the other logos are bright in one case and dim in the other case. Can't we use that? If it is really not possible to detect if the password field is unfocussed then this is a pretty messed up bug in sddm that should definitely be reported and fixed by adjusting the design.

[SergioAtSUSE]

ok, I can agree with an UX bug. There should be a unambiguous difference between a focused and an unfocused textbox.

Creating the bug and adapting the test.

[okurz]

That should be most likely an upstream bug. Have you looked on bugs.kde.org if maybe there is one already? But honestly I am not yet sure if that is really the problem. As I stated: IMHO the two screens do look quite different

[SergioAtSUSE]

I didn't.

I have found a list of bugs that could be related. bugs.kde.org redirected me to https://github.com/sddm/sddm for sddm bugs.

I put here the list to carefully check them tomorrow (I just did a quick look):

• Strange behaviour while using alternative themes for SDDM sddm/sddm#990 (theme problem?)
• No focus and unresponsive keyboard until click with dual monitor sddm/sddm#859 (No focus and unresponsive keyboard until click with dual monitor)
• Focus is not on password field sddm/sddm#612 (Focus is not on password field after boot)
• Add better visual feedback when password is wrong sddm/sddm#363 (visual feedback problems)

At least openQA and in my monitors I don't see any difference in the textbox. I will try to use it manually to see if there is another element in the screen that can give a hint about a focused password textbox

[okurz]

Does

convince you? The upper half is "focussed", the lower is "unfocussed", e.g. by manually selecting the key below the textfield. The "focussed" field has a blurry blue-ish border

[rwx788]

Don't we need needles for SLE? Or this issue doesn't occur there?

[SergioAtSUSE]

Don't we need needles for SLE? Or this issue doesn't occur there?

Good point.

I as can see, the test module is only used by opensuse:

sergio@sergio-latitude:~/github/os-autoinst-distri-opensuse$ git --no-pager  grep user_gui_login
lib/main_common.pm:    loadtest "x11/user_gui_login" if is_opensuse && !get_var("LIVETEST") && !get_var("NOAUTOLOGIN");

[SergioAtSUSE]

I still need to rebase the commits

[SergioAtSUSE]

Ready to be reviewed (and merged)

[fcrozat]

Please revert this NOW, this is breaking all openQA tests on SLE15 SP1.

[nilxam]

and all leap tests.

[SergioAtSUSE]

Fixing it in: #6669