New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 781845 link

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