Bug 1998356

Summary:	Screen Locking Failure "Lock was blocked by application"
Product:	Red Hat Enterprise Linux 8	Reporter:	Brandon Clark <brclark>
Component:	gnome-shell	Assignee:	Florian Müllner <fmuellner>
Status:	CLOSED CANTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	high	Docs Contact:
Priority:	medium
Version:	8.4	CC:	alanm, amike, brclark, casantos, jadahl, jwright, mbliss, mkolbas, sbarcomb
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-15 14:02:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Brandon Clark 2021-08-26 22:17:20 UTC

Description of problem:
When attempting to lock screen, the following error is observed:
	“Lock was blocked by an application”

The line outputted by the messages log is the following:

	gnome-shell[22519]: pushModal: invocation of begin_modal failed
	gnome-shell[22519]: pushModal: invocation of begin_modal failed
	gnome-shell[22519]: error :Unable to lock: Lock was blocked by an application

Certain applications such as firefox an gnome-terminal are two applications that were observed by the customer this was opened for that could cause this behavior. It appears that the screen lock signal is even ignored wholesale in certain cases as it is not registered in dbus diagnostic output.

Version-Release number of selected component (if applicable):
gdm-3.28.3.39.el8.x86_64
libXi-1.7.10-1.el8.x86_64
gnome-shell-3.32.2-30.el8.x86_64
dbus-1.12.8-12.el8_4.2.x86_64


How reproducible:
Consistent

Steps to Reproduce:
	1)Install system via a kickstart with STIG implemented, though with FIPS disabled. Ensure 'use_nfs_home_dir is set to "on"'.
	2) Login
	3) Attempt to induce issue by idle or <Super>l combination while programs such as firefox or gnome-terminal are open.

Actual results:
	Error output 

Expected results:
	Screen locks successfully.

Additional info:
	I was unable to reproduce this behavior myself after considerable testing. This issue is evident in RHEL 7 as well, though customer confirmed they observed it in 8.

Comment 1 Florian Müllner 2021-08-27 11:29:13 UTC

The most likely reason is what the warning message says: An application has grabbed the keyboard or pointer (most probably because of an open (popup) menu).

Not locking the screen is the best we can do in that situation. The alternative leaves the user without a way to unlock the session in the best case, and sends the password to the application that holds the grab in the worst case.

So unless there's an indication that the failure is not triggered by an existing grab, this is WONTFIX/CANTFIX.

Comment 2 Steve Barcomb 2022-02-15 14:02:35 UTC

Marking this bug closed since we have not heard back for sometime and the customer case is closed.  If there is renewed interest in this bug please reach out to me directly.

-Steve