Ticket #330 (closed defect: wontfix)

Opened 12 years ago

Last modified 12 years ago

lock screen from panel needs multiple tries

Reported by: kaduk Owned by:
Priority: low Milestone: Fall 2009 Release
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

If I choose "lock screen" from the power-button-icon dropdown on the panel, there is no effect the first time. Usually on the second attempt it will work, but sometimes it takes four or five tries to
see a response.
I suspect that this has to do with needing a background gnome-screensaver process before screensaving actually works, though I haven't really investigated what is going on.

Change History

comment:1 Changed 12 years ago by jdreed

WFM. Can anyone else reproduce?

comment:2 Changed 12 years ago by jdreed

Actually, doesn't WFM with my test account. I can reproduce this, but only if I try to lock the screen shortly after logging in. If I log in, and leave the machine alone for 5 minutes, and come back, and Lock Screen, it works.

I believe this is part of a bigger problem, namely that GNOME is still grinding away under the hood for a good minute or so even after the panel and Terminal window are available.

comment:3 Changed 12 years ago by andersk

I remember hearing that at some point an intentional delay was added to gnome-screensaver startup in order to help the rest of the desktop load faster.

comment:4 Changed 12 years ago by rbasch

There is indeed apparently a 30-second delay in gnome-settings-daemon before starting the screensaver. See:

 https://bugs.launchpad.net/gnome-screensaver/+bug/354792
 http://bugzilla.gnome.org/show_bug.cgi?id=582587

This has been effectively addressed in upstream gnome by removing the screensaver plugin from g.s.d., in favor of adding a .desktop file to autostart the screensaver:

 http://bugzilla.gnome.org/show_bug.cgi?id=585485

This suggests a likely workaround for us, if we care enough not to wait for the fix to appear in Ubuntu.

comment:5 follow-up: ↓ 6 Changed 12 years ago by broder

I'm in favor of letting this trickle down to us from upstream, especially if it's the behavior on vanilla Jaunty, but I don't feel strongly about the issue.

I will point out that if this was only fixed in upstream GNOME in mid-July, it's very unlikely to make it into Karmic, but the change probably will make Karmic+1. So clusters wouldn't see this change until the summer 2010 deployment.

comment:6 in reply to: ↑ 5 Changed 12 years ago by andersk

Replying to broder:

I will point out that if this was only fixed in upstream GNOME in mid-July, it's very unlikely to make it into Karmic,

No, actually it’s very likely—and in fact, it already has.

The Ubuntu release cycle is closely tied to GNOME’s, so new GNOME developments tend to make it into Ubuntu very quickly.

comment:7 Changed 12 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

Fixed upstream.

Note: See TracTickets for help on using tickets.