Bug 508979 - gnome-screensaver ignores input when fading to black
gnome-screensaver ignores input when fading to black
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-30 14:07 EDT by Bryan O'Sullivan
Modified: 2015-01-14 18:23 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 15:16:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bryan O'Sullivan 2009-06-30 14:07:09 EDT
Description of problem:

When gnome-screensaver is fading the screen to black, it doesn't pay any attention to user input that should interrupt the fade and give me my normal interaction back.

Version-Release number of selected component (if applicable):

gnome-screensaver-2.26.1-2.fc11.i586

How reproducible:

100%

Steps to Reproduce:
1. Run "gnome-screensaver-command -a" to get the fade started.
2. Watch the screen start to fade, wiggle the mouse, hit a key.
3. The screen still locks.
  
Actual results:

The screen fades to black and locks, but it takes a couple of seconds.

Expected results:

Either the screen should immediately drop into locked mode and present me with a password input (much less desirable, but okay), or it should restore me to normal interaction.  Having it ignore my input, then fade to black, and require me to hit another key after waiting for the fade to complete, is impressively frustrating considering how minor it sounds.
Comment 1 James 2009-08-08 18:05:29 EDT
I've had this happen automatically after the timeout, e.g. when watching a Flash video, and gss doesn't respond to input events but continues fading. For some reason, under this circumstance the fade is slower than usual.
Comment 2 Denny Crane 2009-08-26 23:56:04 EDT
Having the same problem. Exceptionally annoying in my case since I set my screensaver to a 1 or 2 minute activation for security reasons. It does seem that the fade is slower in these cases, as the previous poster states, but I was assuming that was my imagination. The problem seems to be more likely the longer the user has been logged-in. For example, if I restart my computer, the first time or first few times it starts to fade, I can recover by moving my mouse. However, eventually the problem starts and it does not go away until I restart my machine (perhaps logging out would accomplish the same goal, I do not know).
Comment 3 jmccann 2009-09-02 15:16:50 EDT
There are two fades.  One is when fading slowly to indicate that the screen is about to lock.  This one is interruptable.  The other is the quicker fade out to a locked screen.  This is not interruptable.  If you are having problems with the first case please file a bug in GNOME bugzilla for this.  I'm not able to reproduce this.

The problem that is mentioned in the initial report sounds like the second case.  And that is by design.
Comment 4 Denny Crane 2009-09-02 15:25:57 EDT
How does it sound like the second case?? Why would anyone want to "interrupt" the second case? How could anyone "interrupt" something that happens so quickly? How could you "interrupt" it in the first place if the change is already based upon the user taking an action?
Comment 5 jmccann 2009-09-02 17:09:58 EDT
It sounds like the second case because of step 1 in the original message.
Comment 6 Denny Crane 2009-09-02 17:16:33 EDT
Oh, I thought you were referring to an "unfading" fade from screensaver to lock screen, since you said that it was a "fade out to locked screen" which is not accurate because it is still fading to a screensaver.

In any case, I think the original poster was simply trying to show how this bug can be reproduced (without waiting), not knowing that calling that command treats the fade differently. I could be wrong though.
Comment 7 Tim Taiwanese Liim 2009-09-03 16:03:28 EDT
Re: Comment #3
I have problem with the first case indeed, always reproducible in F11.
Same as Nate, I set screensaver to 1 minute timeout at work, security
reasons.  The slow fade is uninterruptible, very annoying.  It used to
be interruptible in F10.

So the solution is to open a bug in GNOME bugzilla.  Sounds good.
Comment 8 Denny Crane 2009-09-03 16:06:50 EDT
Tim,

Let us know the link if you make that post; I haven't gotten around to it yet myself.
Comment 9 Tim Taiwanese Liim 2009-09-03 17:09:29 EDT
Filed a bug at gnome bugzilla just now.
    http://bugzilla.gnome.org/show_bug.cgi?id=594082
Please send your support evidence there.  Thanks.
Comment 10 Dams 2009-09-05 10:49:45 EDT
FWIW, It doesnt happen to me anymore. Though i'm happy with that, it's still a bit strange because I dont know why it doesnt happen anymore.
Comment 11 Denny Crane 2009-09-12 22:42:43 EDT
Problem went away for me after this morning's Fedora 11 updates were installed:

Sep 12 06:45:57 Updated: lohit-fonts-common-2.4.0-1.fc11.noarch
Sep 12 06:45:58 Updated: gnome-python2-extras-2.25.3-7.fc11.i586
Sep 12 06:46:27 Updated: selinux-policy-3.6.12-82.fc11.noarch
Sep 12 06:46:28 Installed: wine-fonts-1.1.29-1.fc11.noarch
Sep 12 06:47:03 Updated: selinux-policy-targeted-3.6.12-82.fc11.noarch
Sep 12 06:47:06 Updated: lohit-maithili-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:09 Updated: lohit-telugu-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:12 Updated: lohit-hindi-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:15 Updated: lohit-kannada-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:18 Updated: lohit-punjabi-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:21 Updated: lohit-gujarati-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:24 Updated: lohit-bengali-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:27 Updated: lohit-tamil-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:30 Updated: lohit-oriya-fonts-2.4.0-1.fc11.noarch
Sep 12 06:47:51 Installed: wine-core-1.1.29-1.fc11.i586
Sep 12 06:47:57 Updated: xulrunner-1.9.1.3-1.fc11.i586
Sep 12 06:47:59 Updated: gnome-python2-gtkmozembed-2.25.3-7.fc11.i586
Sep 12 06:48:00 Updated: wine-cms-1.1.29-1.fc11.i586
Sep 12 06:48:01 Updated: wine-pulseaudio-1.1.29-1.fc11.i586
Sep 12 06:48:01 Updated: wine-ldap-1.1.29-1.fc11.i586
Sep 12 06:48:02 Updated: wine-capi-1.1.29-1.fc11.i586
Sep 12 06:48:03 Updated: wine-twain-1.1.29-1.fc11.i586
Sep 12 06:48:04 Updated: cloog-ppl-0.15.7-1.fc11.i586
Sep 12 06:48:06 Updated: postgresql-libs-8.3.8-1.fc11.i586
Sep 12 06:48:21 Updated: Miro-2.5.2-4.fc11.i586
Sep 12 06:48:47 Updated: yelp-2.26.0-7.fc11.i586
Sep 12 06:48:49 Updated: wine-nas-1.1.29-1.fc11.i586
Sep 12 06:48:50 Updated: wine-jack-1.1.29-1.fc11.i586
Sep 12 06:48:51 Updated: wine-esd-1.1.29-1.fc11.i586
Sep 12 06:48:52 Updated: gnome-python2-libegg-2.25.3-7.fc11.i586
Sep 12 06:48:53 Updated: gnome-python2-gtkhtml2-2.25.3-7.fc11.i586
Sep 12 06:48:54 Updated: alsa-plugins-pulseaudio-1.0.21-2.fc11.i586
Sep 12 06:48:55 Updated: wine-desktop-1.1.29-1.fc11.noarch
Sep 12 06:48:57 Installed: wine-common-1.1.29-1.fc11.noarch
Sep 12 06:49:02 Updated: firefox-3.5.3-1.fc11.i586
Sep 12 06:49:03 Updated: wine-1.1.29-1.fc11.i586
Sep 12 06:49:30 Erased: wine-tools
Comment 12 Tim Taiwanese Liim 2009-09-13 00:55:33 EDT
Me too, problem went away; still no idea why/how.
Good anyway.

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