Project

General

Profile

action #13214

Next button is ignored in user_settings but works on second try

Added by mkravec over 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2016-08-16
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Command send_key $cmd{next} is ignored in user_settings or pressed too fast. Test then writes root passwords on user screen.

Next button works on second try (from user_settings_root), so I think this is openqa issue.

https://openqa.suse.de/tests/518168#step/user_settings/4


Related issues

Related to openQA Tests - action #14102: [Build 2162] test user_settings_root fails to type confirmation password in second fieldResolved2016-10-07

History

#1 Updated by okurz over 6 years ago

  • Assignee set to mkravec

I am not sure this is entirely correct. The corresponding log excerpt is:

16:01:59.8032 17414 >>> testapi::_check_backend_response: found inst-userinfostyped-20160504, similarity 1.00 @ 523/222
16:01:59.8033 Debug: /var/lib/openqa/share/tests/sle/tests/installation/user_settings.pm:30 called testapi::check_screen
16:01:59.8034 17414 <<< testapi::check_screen(mustmatch='autologindisabled', timeout=30)
…
16:02:00.2425 17414 >>> testapi::_check_backend_response: found autologindisabled-20160504, similarity 1.00 @ 567/525
16:02:00.2426 Debug: /var/lib/openqa/share/tests/sle/tests/installation/user_settings.pm:40 called testapi::send_key
16:02:00.2427 17414 <<< testapi::send_key(key='alt-n')
16:02:00.4440 Debug: /var/lib/openqa/share/tests/sle/tests/installation/user_settings.pm:44 called testapi::check_screen
16:02:00.4442 17414 <<< testapi::check_screen(mustmatch='inst-userpasswdtoosimple', timeout=13)
…
16:02:13.4411 17421 no change 0
16:02:14.6922 17421 MATCH(inst-userpasswdtoosimple-20160504:0.00)
16:02:14.6933 17414 >>> testapi::_check_backend_response: match=inst-userpasswdtoosimple timed out after 13
16:02:14.7583 Debug: /var/lib/openqa/share/tests/sle/tests/installation/user_settings.pm:48 called testapi::record_soft_failure
16:02:14.7584 17414 <<< testapi::record_soft_failure(reason='bsc#937012')
…
16:02:14.7603 Debug: /var/lib/openqa/share/tests/sle/tests/installation/user_settings_root.pm:19 called testapi::assert_screen
16:02:14.7604 17414 <<< testapi::assert_screen(mustmatch='inst-rootpassword', timeout=30)
…
16:02:45.6280 17414 >>> testapi::_check_backend_response: match=inst-rootpassword timed out after 30

So it finds the 'autologindisabled' which is the last correct screenshot shown. Then it presses 'alt-n' and checks for the dialog 'inst-userpasswdtoosimple' which doesn't show up in 13 seconds. The next action after recording soft failure is the assert_screen for 'inst-rootpassword' which also times out so there is no typing after the password except for the 'alt-n' itself.

From the y2logs on https://openqa.suse.de/tests/518168/file/user_settings_root-y2logs.tar.bz2 in YaST2/macro_inst_initial.ycp I can see what the installer got as input. The last entry block there is

    {
        //
        // 2016-08-16 12:02:00

        UI::ChangeWidget( `id (`new_user),  `Value, true ); // YRadioButton "Create New User"
        UI::ChangeWidget( `id (`full_name), `Value, "Bernhard M. Wiedemann" );  // YInputField "User's Full Name"
        UI::ChangeWidget( `id (`username),  `Value, "bernhard" );   // YInputField "Username"
        UI::ChangeWidget( `id (`root_pw),   `Value, false );    // YCheckBox "Use this password for system administrator"
        UI::ChangeWidget( `id (`autologin), `Value, false );    // YCheckBox "Automatic Login"

        // UI::MakeScreenShot( "/tmp/yast2-0045" );
        UI::FakeUserInput( `next );

        return;
    }

See the last UI::FakeUserInput( next ); ? I read this that the installer actually got the 'alt-n' and interprets it as 'next' but then still fails. The file y2log does not show an obvious error to me so I suggest you make this a proper bugzilla bug.

#2 Updated by mkravec over 6 years ago

  • Status changed from New to Closed

Test has passed in last 2 builds, I think we can close this poo.

https://openqa.suse.de/tests/519315

#3 Updated by okurz over 6 years ago

  • Status changed from Closed to In Progress

Let's try the following: Find a useful hypothesis what could be the cause for each failure and close a ticket only with at least one accepted hypothesis. I hope you won't be mad at me but I guess this could be the best way for us to learn what could break :-)

#5 Updated by okurz almost 6 years ago

  • Related to action #14102: [Build 2162] test user_settings_root fails to type confirmation password in second field added

#6 Updated by okurz almost 6 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF