Bug 1258418 - System is not locked when menu is present
System is not locked when menu is present
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Florian Müllner
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-31 06:46 EDT by Oliver Haessler
Modified: 2015-09-04 09:19 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-04 09:19:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Oliver Haessler 2015-08-31 06:46:50 EDT
Description of problem:
If a right click menu is opened, Gnome 3 is not locking (neither via Win+L or Ctrl-Alt+L or after the lock timeout)

Version-Release number of selected component (if applicable):
gnome-shell-3.8.4-45.el7.x86_64

How reproducible:
Every time a right click menu is present

Steps to Reproduce:
1. right click in any app (Firefox, LibreOffice, Terminal)
2. press the lock keyboard shortcut (Win+L or Ctrl-Alt+L) or wait for the lock timeout

Actual results:
System is not locked

Expected results:
System is locked

Additional info:
Comment 2 Florian Müllner 2015-09-04 09:19:13 EDT
(In reply to Oliver Haessler from comment #0)
> Description of problem:
> If a right click menu is opened, Gnome 3 is not locking

Indeed. That is because popup menus usually grab pointer and keyboard, so our own attempts to grab those for locking the screen fail. There is nothing we can do about this except for showing the lock screen while the screen is not actually locked (i.e. pointer and keyboard input still goes to applications), which would be a complete disaster. While not locking the screen isn't great either, it is unfortunately the best we can do ...

Note You need to log in before you can comment on or make changes to this bug.