New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Started
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Sign in to add a comment

desktopui_ScreenLocker failing on amd64-generic and betty

Project Member Reported by, Nov 6 2017

Issue description

desktopui_ScreenLocker started failing on amd64-generic here:

The failure output is here:


11/03 19:09:42.002 INFO |           browser:0283| Browser is closed.
11/03 19:09:42.020 WARNI|              test:0612| The test failed with the following exception
Traceback (most recent call last):
  File "/usr/local/autotest/common_lib/", line 606, in _exec
    _call_test_function(self.execute, *p_args, **p_dargs)
  File "/usr/local/autotest/common_lib/", line 806, in _call_test_function
    return func(*args, **dargs)
  File "/usr/local/autotest/common_lib/", line 470, in execute
  File "/usr/local/autotest/common_lib/", line 347, in _call_run_once_with_retry
    postprocess_profiled_run, args, dargs)
  File "/usr/local/autotest/common_lib/", line 380, in _call_run_once
    self.run_once(*args, **dargs)
  File "/usr/local/autotest/tests/desktopui_ScreenLocker/", line 166, in run_once
  File "/usr/local/autotest/tests/desktopui_ScreenLocker/", line 100, in lock_screen
    exception=error.TestFail('Screenlock screen not visible'))
  File "/usr/local/autotest/common_lib/", line 2740, in poll_for_condition
    raise exception
TestFail: Screenlock screen not visible

Status: Started (was: Assigned)
I am going to start with seeing if I can repro this locally while I look at the chrome output.

This seems suspicious: :)

"cros: Enable views-based lock by default."

I am hoping that I will be able to repro with a Simple Chrome VM test:

From the Chrome log:

[1093:1093:1103/] PostLockAnimationFinished
[1093:1093:1103/] PreLockAnimationFinished
[1093:1093:1103/] Not implemented reached in virtual void chromeos::ViewsScreenLocker::OnAshLockAnimationFinished()
[1093:1093:1103/] Deleting ScreenLocker 0x24fe5e389900
[1093:1093:1103/] Destroying ScreenLocker 0x24fe5e389900
[1093:1093:1103/] Emitting SCREEN_LOCK_STATE_CHANGED with state=0
[1093:1093:1103/] Calling session manager's HandleLockScreenDismissed D-Bus method

So it sounds like we should revert the change until we fix the test?

I'm a little curious why it is only failing on those boards, but maybe we don't run that test elsewhere?

jdufault@ - WDYT, is it safe/OK to revert that?

jdfault@ is MIA and I can not reprduce the VM failure locally, but as mentioned in comment #5 this is almost certainly so I am going to try reverting that.

Reverting is fine, if you haven't started the revert yet please reassign to me and I'll take care of it.
Assigning to jdufault@ to close once the CL is reverted or to track fixing the test.

Views-based support for desktopui_ScreenLocker is tracked in issue 781998, I'm going to force the test to always load webui lock screen in the meantime.
Project Member

Comment 11 by, Nov 10 2017

The following revision refers to this bug:

commit 40a690f27f05572a0553b47140668651fd83f45a
Author: Jacob Dufault <>
Date: Fri Nov 10 03:16:32 2017

Force desktopui_ScreenLocker to use webui lock screen

TEST=test_that --board=$BOARD <ip> desktopui_ScreenLocker

Change-Id: I38aff94e029749dfebc966f3989d5abfac027c83
Commit-Ready: Jacob Dufault <>
Tested-by: Jacob Dufault <>
Reviewed-by: Ilja H. Friedel <>


Components: Infra
Components: -Infra Infra>Client>ChromeOS
[It appears that a bunch of old cros issues bulk-added the "Infra" component recently, but they should probably be "Infra>Client>ChromeOS".]

Sign in to add a comment